[cmake-developers] Fwd: lua bindings?

Doug douglas.linder at gmail.com
Fri Aug 3 20:51:45 EDT 2012


Woops; wrong reply button. :P

---------- Forwarded message ----------
From: Doug <douglas.linder at gmail.com>
Date: Sat, Aug 4, 2012 at 8:07 AM
Subject: Re: [cmake-developers] lua bindings?
To: Brad King <brad.king at kitware.com>


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.

However, ive never really been very happy with cmake functions and
macros, and writing a script to do these tasks is annoying in cmake
itself.

I'm presently using a c boost strap, which compiles into an
application that runs, parses files, and generates a cmakelists.txt.
Then running cmake again on the result.

...but I'm not really happy with it. So i started to experiment with a
lua runner, which was executed by execute_process()  followed by
add_subdirectory() and that led me to wondering about complex build
scripts and lua integration.

The only real benefit of a lua wrapper would be it has zero impact on
the code base, and does not depend on the code itself; a (for example)
2.8.x wrapper could continue to function even long after 2.8 is no
longer the most recent so long as no backwards incompatible language
syntax changes were made.

Sharply in contrast, a 2.8 fork with lua bindings would become
obsolete almost immediately and require constant remerging to remain
functional.

Even if i supported it for a month or year, eventually id move on and
the project would get abandoned unless it was officially adopted; and
that seems unlikely.

Tangibly the benefits of a script in lua this way for me would be:

- modularised code base support,  real language constructs

Ie. better than cmakes include and add directives with search paths,
all the normal lua stuff.

- complex build augmentation via dynamic library loading

Making cmake into the kitchen sink aka python with a million of its
dependencies isnt a great idea.

However, if you do need complex build rules, you could have an
external module (automake portability tools, certificate signing,
reading zipfiles)  that was invoked as a subproject and built by cmake
then loaded as a dynamic lua extension and then the build could
continue.

This 'build binaries,  then continue build scripts' approach is, as
far as i can tell, simply not possible from cmake at the moment;
execute process is as close as you can get.

That said, its not without challenges. Particularly build progress
(90%...but wait that was only the first cmake call...) and cmake
configuration ccmake, etc. are something i havent figured out yet.

~
Doug.

On Aug 4, 2012 4:55 AM, "Brad King" <brad.king at kitware.com> wrote:
>
> 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



More information about the cmake-developers mailing list