[cmake-developers] lua bindings?

[Doug]

Sorry, lots of talk. Tangibly I imagine something like this:

local helper = cmake:context()
helper.set_build_dir("helper")
helper.configure("-DBUILD_TESTS=ON")
helper:file("GLOB_RECURSE", "SOURCES", "${CMAKE_CURRENT_SOURCE_DIR}/*.c")
helper:add_library("help", "SHARED", "${SOURCES}")

helper:get_property("HELP_LIB", "TARGET", "help", "PROPERTY", "LOCATION")
helper:configure_file("${PROJECT_SOURCE_DIR}/config.in",
"${PROJECT_BINARY_DIR}/config")
helper.generate()
helper.compile()

fp = io.open("helper/config", "r")
help = fp:read("*all")
fp:close()

local factory,err = package.loadlib(help,'luaopen_help')
if not fn then print(err)
else
  helper = factory()
end

app = cmake:context()
app.set_build_dir("app")
helper.set_automake_path("lib/tools/openssl-1.0.1c")
helper.automake(app)
app.generate()
app.compile()

Note that this is not a dynamic invokation of cmake; you cannot go:
files = helper.get_value("SOURCES"); foreach i, k in pairs(files) ...
or similar because this is a cached script builder, not a dynamic
script evaluator.

This sucks in some ways, but vastly lowers the complexity of implementing it.

~
Doug.


On Sat, Aug 4, 2012 at 6:10 AM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> On 8/3/2012 5:30 PM, Óscar Fuentes wrote:
>>
>> Brad King <brad.king at kitware.com> writes:
>>
>> [snip]
>>
>>> As for your first option, a "zero-impact wrapper", what do you
>>> envision would be the benefits?
>>
>>
>> [I'm not the OP]
>>
>> Something I sorely miss on CMake is a way to express algorithms in a
>> clear way and to process large amounts of data efficiently.
>>
>> For an example that could benefit from a cleaner and more expressive
>> language, see function explicit_map_components_to_libraries in
>>
>>
>> http://www.llvm.org/viewvc/llvm-project/llvm/trunk/cmake/modules/LLVM-Config.cmake?revision=145355&view=markup
>>
>> On the same project, there was several perl scripts that I'll like to
>> implement on CMake (and hence drop the Perl requirement.) Those scripts
>> walked through all defined and referenced symbols on all libraries on
>> the project for creating library dependencies. On another instance, a
>> similar taks would be performed on Visual C++ for creating .def files
>> and dll's. On both cases I stumbled on the language's lack of
>> expresiveness, minimal support for data structures and on an apparent
>> O(n^2) time complexity on some list operations (including the append
>> operation, IIRC)
>>
> So, we have talked about this at Kitware some recently and came up with a
> gradual approach that should work.
>
> 1. Add lua to cmake as a command.  Something like cmake -E tar, but cmake -E
> lua.  This would mean that lua would always be something you could count on
> having with cmake.
>
> 2. Add a simple integration into the cmake language that lets you evaluate
> lua inside a cmake file.  Something like eval_lua("...").
>
> 3. If 1 and 2 go well, investigate binding the cmake commands into lua.
> (LuaCMake)
>
> With this approach there would be benefit to the whole cmake community from
> Lua.  You would not have to convert your project to LuaCMake (3) to take
> advantage of more expressive language.  You could just eval some lua
> statements in an existing large cmake project.  I would not want to fork
> cmake into lua cmake and cmake cmake, but this path forward would avoid
> that.
>
> All that said, we do not at the moment have funding for such a project at
> Kitware.
>
> -Bill
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers