Initial Task List

3 views
Skip to first unread message

E. Wing

unread,
Dec 31, 2007, 12:05:40 AM12/31/07
to cmak...@googlegroups.com
So here's my (work-in-progress) task list:

Repository stuff:
Is there an easy way to make a public authoritative Tailor repository
that people can pull but can't push to and a way to automate the
CVS/Hg synchronization? Is there a way to automate resync on some kind
of change-notification trigger with the official repo? And should we
consider auto-merging changes into the official CMakeLua tree? If so,
how do we approach merge conflicts. Can we do this in a way that is
distributed so I don't become a bottleneck?

- Figure out how to strip Windows style carriage returns on commit (or
push) in the main repository. (Also add them back for Windows
checkout?)


Code:

- Refactor Lua integration. Try to reduce possibilities of future
merge conflicts. Refactor in such a way that bindings to other
languages may benefit from our design?

- Put CMake API functions into namespace 'cmake'.

- Expose CMake constants to Lua variables. Also place in namespace
'cmake' (e.g. math.pi)? Should we setup the metatables so the
variables are read-only?


- Focus on LuaPublicAPIHelper.lua in Modules directory:
- Change to use 5.1 module conventions
- Figure out how to apply smart argument handling to all CMake public
API functions dynamically (so we don't have to write a wrapper for
each function)
- Could benefit from a luaL_require from C.
- Need to work with module system to made require search in standard
CMake paths before anything else. Not sure if we should allow system
installed Lua modules to be read? (How do we deal with compatibility
problems?)

- Any API functions not bound via C++ due to being implemented in
CMake-script need to be ported.

- Converter for CMake-script to Lua

- Look at CMake variable system. May need to integrate Lua variables
into it. Also may benefit hugely if CMake-script variables and
Lua-variables can interoperate. This will allow hybrid projects where
a Lua script may be able to call an existing CMake script and read its
variables. This would help adopters with large existing code bases.


- Embed lrexlib and or lpeg. Should we attempt to statically link
these in, or use as modules?

- Fix bootstrap system. Start with assuming Lua is always embedded. Do
we extend to also allow dynamically linked/pre-installed Lua? (There
is difficulty ensuring versions are compatible.) Bootstrap should also
handle lrexlib/lpeg once added. Static linking seems to make a lot of
problems go away.


- Need to develop some good unit tests.

- Are there good documentation generation systems like Doxygen for lua
5.1? (luadoc?)


Thanks,
Eric

Reply all
Reply to author
Forward
0 new messages