Resync attempt in repo (merge conflicts) and random thoughts

1 view
Skip to first unread message

E. Wing

unread,
Feb 1, 2008, 11:23:44 PM2/1/08
to cmak...@googlegroups.com
Hi gang,
I've been really busy with other tasks, but I had a moment to tinker.
I tried to resync against the official CVS. It produced some
unpleasant merge conflicts in:
cmGetProperyCommand.cxx
cmMakefile.cxx

I'm not sure if my manual merge attempts succeeded. I haven't yet
tested it. Can any of you guys test? Changes are pushed into the
Assembla repo.

Also, a couple of quick thoughts/tasks.

First, I am not completely sure and need to recheck, but I think the
current CMake function binding uses the variable number of arguments
to pass the parameters from Lua to CMake. If so, I'm concerned that
this may blow the stack. I thought I read somewhere that the limit for
var-args is 2048. (#define in Lua). For really long file lists, this
could be trouble if true. I think we should probably convert the
system to pass long lists through a table instead where I believe the
number of arguments is practically unlimited.

Second, I've been thinking more about the variable situation. I'm
starting to think that the ability to directly interact with CMake's
current variable system may be more crucial than I initially thought.
I realized there are a bunch of CMake defined values like $ENV{FOO}
and ${CMAKE_PROJECT_DiR} that probably need to hook into this system
to work. If we do have to hook in, I'm wondering if that means we
already did the bulk of the work to interoperate with variables which
would make interaction with native CMake scripts feasible.


Third, a more random thought about how CMake specifies functions. They do a:
FunctionName(KEYWORD PARAM1 PARAM2 KEYWORD PARAM ... KEYWORD ...)
type system which always seemed a little odd to me. I think we need to
support this, but I'm wondering if we should also support a 'named
parameter' system, where basically we pass a table and each KEYWORD is
a key in the table. Though I'm not yet sure if this will break down
for optional parameters (or parameters that just have a presence but
no value) as you can't have nil as a value and we lose order in a
table.

Fourth, any volunteers to make my current:
LuaPublicAPIHelper.lua
conform to 5.1 module conventions? And I think we need something like
luaL_require() and control the lua module so it looks in CMake places
first (and only?)

Thanks,
Eric

E. Wing

unread,
Feb 2, 2008, 5:20:06 AM2/2/08
to cmak...@googlegroups.com
Yeah, it looks like I missed something. Some function signatures
changed (specifically ExecuteCommand) which required more changes. I
checked in more fixes. I did manage to build and run the lua test
program.

Thanks,
Eric

Reply all
Reply to author
Forward
0 new messages