Re: [cmake-developers] lua bindings?
Here an example how a Lua based build system could look like: https://github.com/deplinenoise/tundra/blob/master/tundra.lua And more details here: http://deplinenoise.files.wordpress.com/2011/04/tundra43.pdf Peter -- 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
Re: [cmake-developers] lua bindings?
On Thursday 23 August 2012, Peter Kümmel wrote: Here an example how a Lua based build system could look like: https://github.com/deplinenoise/tundra/blob/master/tundra.lua And more details here: http://deplinenoise.files.wordpress.com/2011/04/tundra43.pdf So, another buildsystem for cmake to target ? Alex -- 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
Re: [cmake-developers] lua bindings?
On 08/03/2012 08:51 PM, Doug wrote: helper.set_automake_path(lib/tools/openssl-1.0.1c) helper.automake(app) [snip] On 08/03/2012 08:51 PM, Doug wrote: I've found lately that I am using increasingly complex scripts to convert existing automake projects (notably freeglut, openssl 1.0.1 and freetype) to cmake. These projects dont support cmake directly, and dont really have any intention of doing so, and the only way to cleanly support them in a way that doesnt break from release to release (or at least has minimal impact) is to load and process the automake files. I realize this is terrible, but practically speaking it works relatively well. If your goal is to include third-party autotools builds under your CMake projects, consider using the ExternalProject module: http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html -Brad -- 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
Re: [cmake-developers] lua bindings?
On 8/3/12, Doug douglas.lin...@gmail.com wrote: Sorry, lots of talk. Tangibly I imagine something like this: I recommend you skim the CMakeLua group for the old posts. (There aren't that many.) https://groups.google.com/forum/?fromgroups#!forum/cmakelua If I recall, Peter Kümmel had some interesting ideas/code for interoperating/mixing with existing CMake scripts. This may impact the direction you take the Lua side of the bridge syntax/semantics, but has the advantage of being able to coexist with and leverage the existing CMake ecosystem. https://groups.google.com/forum/?fromgroups#!topic/cmakelua/aVx3K-Y7H6M -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- 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
Re: [cmake-developers] lua bindings?
On 8/2/12, Doug douglas.lin...@gmail.com wrote: I'm quite curious about the possibility of writing a lua binding for cmake. There are two possible ways to go: 1) Create a set of discrete lua bindings which actually invoke cmake itself. 2) Integrate lua into cmake itself. Yes, there was a big long thread on the CMake lists back in 2008-ish (CMake and Lua ). It prompted Dr. Ken Martin (Kitware) to try an experiment of embedding Lua in CMake which actually successfully proved the binding concept. Unfortunately, Kitware decided they didn't want to put the resources into it. A few of us forked the project, but we failed to continue to finish it. But the source is still out there. Some info is here: http://playcontrol.net/ewing/jibberjabber/cmake_lua.html and http://www.cmake.org/Wiki/CMake:Experiments_With_Lua I am still very interested in seeing this happen, but I had to pick to between binding Lua to Cocoa (LuaCocoa) or CMake and I did LuaCocoa. And now, I am now preoccupied with porting LuaCocoa to iOS. (And we also have a lot of pain right now with CMake and the ever-changing/breaking Xcode.) -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- 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
Re: [cmake-developers] lua bindings?
On 08/03/2012 04:33 PM, Eric Wing wrote: Yes, there was a big long thread on the CMake lists back in 2008-ish The main two threads started here: http://www.cmake.org/pipermail/cmake/2007-November/017347.html http://www.cmake.org/pipermail/cmake/2007-November/017971.html Ken's experiment only scratched the surface. There are many very hard problems with trying to replace the CMake language with Lua directly in CMake itself. For historical reasons a large part of the build system generators are tied to the CMake language implementation. The language has some unique semantic properties which cannot be reproduced cleanly in Lua, and we probably wouldn't want them in a new language anyway. Direct replacement is not feasible. Perhaps some major internal redesign and refactoring could possibly split the generation part off into a private SDK shared by the existing language and some new language, but it would be a huge effort. As for your first option, a zero-impact wrapper, what do you envision would be the benefits? -Brad -- 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
Re: [cmake-developers] lua bindings?
Brad King brad.k...@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=145355view=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) -- 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
Re: [cmake-developers] lua bindings?
On 8/3/2012 5:30 PM, Óscar Fuentes wrote: Brad King brad.k...@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=145355view=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
Re: [cmake-developers] lua bindings?
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.hoff...@kitware.com wrote:
On 8/3/2012 5:30 PM, Óscar Fuentes wrote:
Brad King brad.k...@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=145355view=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
--
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
[cmake-developers] lua bindings?
I'm quite curious about the possibility of writing a lua binding for cmake. There are two possible ways to go: 1) Create a set of discrete lua bindings which actually invoke cmake itself. 2) Integrate lua into cmake itself. Before I go and do anything, has any effort been made to do either of these? From the lua mailing list I get the impression that some discussion of (2) has been done before, and broadly speaking, no one is really interested in re-writing cmake to support lua scripts as first class citizens. However, (1) interests me, because it'd be reasonably trivial to implement a lua binding of commands like: cmake:execute_process cmake:add_library cmake:target_link_library That cached the requests internally and actually generated a cmakelists.txt from it. There are some difficulties with this approach, for example, some actions require an immediate response that can't be cached; eg. file(GLOB) - filtering that list to invoke add_library()... but I think it wouldn't be impossible to generate temporary 'working' cmake files and invoke cmake on them directly, read the response and pipe it back into the lua script. This would be effectively a zero-impact wrapper around cmake, and make supporting more complex programming constructs (poor support for closures, hashes and lists specifically being my pet dislike with the cmake language). So, like I said, before I start down the road of messing around with this, has anyone got any thoughts about it, past experience and suggestions? Cheers, Doug. -- 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
