JamPlus - cmake features - JamPlus

cmake features

I have been searching for a while now for a build system to replace GNU make on something I'm working on. So far, none have the functionality that would make a switch worthwhile. The best thing I can envision is CMake with direct build support. On the other hand, jamplus seems to have most of what I want (with minor glitches), so perhaps jamplus with CMake's excellent library and other features.

Specifically:

- I did not see it immediately, but is there a persistent configuration ability available or planned? I was able to create a simple one using the Lua interface, so it's not a big deal if there is none. Mine only supports -s<var>=<val> and direct editing of the cache for user input, but of course if you had something like ccmake or cmake-gui planned, that would be awesome. What I'd like to do is port all of cmake's library over to this, if it is capable. That plus a few things that never made it into cmake, like gnat support.

- How about easy out-of-tree builds? Not the standard jam variant build thing, but just start in another dir and have everything build there? I suppose some sort of hackery with $(SEARCH) and friends would be needed. I never really cared for the variant build method, and almost all modern build tools use it. Only cmake and autotools seem to properly support ad-hoc out-of-tree variants.

- How about having an include file inserted (persistently), like cmake's -DCMAKE_TOOLCHAIN_FILE=...? I suppose that's easy enough to add in higher-level code, as long as persistent config is available. The combination of this feature and the out-of-tree build feature make cross-compile testing really easy. Of course you'd also have to implement cmake's host/target separate search paths, and other things, I suppose.

- To replace cmake -E and cmake -P, maybe have a way to directly execute lua code without invoking the jam parts? I know that the build copies the lua executable over, so maybe that's not all that important. I'd really like a more static lua as well; maybe have a build option to link it directly (static or dynamic, whichever, just not dlopen()), and some sort of env. var override and/or config option for the ! feature in lua's search paths. Of course that wouldn't take care of the tar and symlink functions, but that could be worked out separately (luafilesys and libarchive?). Having sufficient functionality in the lua makes creating portable builds (i.e., no shell code) pretty easy.

Of course I have no hope of getting GNU make's ability to remake its own makefiles when needed, although queued rebuilds come close (but the inability to defer resolution of command-line targets until the last build makes them useless). Then again, rebuilding the makefiles every time isn't that terribly expensive.

Some of the features I mention may have been implemented by others in the perforce user areas, but I do not wish to wade through a vast unsorted undocumented area for days on end to see if someone else has already done it.

I also wonder why the original jam's install and uninstall targets (and other functionality) were removed, but I guess that's not really important, either. It's easy enough to recreate.

Then again, maybe I'll just try to push forward with scons or waf again. I just don't like python that much (or waf or scons in particular), so I'm spending way too much time trying to avoid it.

Replies (2)

RE: cmake features - Added by Joshua Jensen 10 months ago

Thomas Moore wrote:

- I did not see it immediately, but is there a persistent configuration ability available or planned? I was able to create a simple one using the Lua interface, so it's not a big deal if there is none. Mine only supports -s<var>=<val> and direct editing of the cache for user input, but of course if you had something like ccmake or cmake-gui planned, that would be awesome. What I'd like to do is port all of cmake's library over to this, if it is capable. That plus a few things that never made it into cmake, like gnat support.

There is not a GUI yet for JamPlus, although I have wanted (even needed) a CMake-style GUI for some time.

There are a variety of ways to persist settings for a build. Some are not properly documented in the main JamPlus documentation, but information can be found in the following places:

Description of the .config file format used when creating a new out-of-source build environment: http://jamplus.org/boards/1/topics/280
Command-line flags to jam --workspace: http://jamplus.org/git/jamplus/docs/html/jamtoworkspace.html
Manually specified in the UserSettings.jam found in the out-of-source build directory.

- How about easy out-of-tree builds? Not the standard jam variant build thing, but just start in another dir and have everything build there? I suppose some sort of hackery with $(SEARCH) and friends would be needed. I never really cared for the variant build method, and almost all modern build tools use it. Only cmake and autotools seem to properly support ad-hoc out-of-tree variants.

The following generates the files for a proper out-of-tree build, although you may find that, at times, certain assumptions in Jamfiles need to be fixed up to make everything properly build out of source.

jam --workspace Jamfile.jam /path/to/out/of/tree/build

- How about having an include file inserted (persistently), like cmake's -DCMAKE_TOOLCHAIN_FILE=...? I suppose that's easy enough to add in higher-level code, as long as persistent config is available. The combination of this feature and the out-of-tree build feature make cross-compile testing really easy. Of course you'd also have to implement cmake's host/target separate search paths, and other things, I suppose.

It has been a while since I used CMake. I would have to look into this feature to understand what it does. I'm curious if it can be simulated via the .config file settings described above.

More soon...

-Josh

RE: cmake features - Added by Thomas Moore 10 months ago

Joshua Jensen wrote:

There are a variety of ways to persist settings for a build. Some are not properly documented in the main JamPlus documentation, but information can be found in the following places:

Description of the .config file format used when creating a new out-of-source build environment: http://jamplus.org/boards/1/topics/280

Command-line flags to jam --workspace: http://jamplus.org/git/jamplus/docs/html/jamtoworkspace.html

Manually specified in the UserSettings.jam found in the out-of-source build directory.

OK, thanks. I suppose I'll have to look at that in more depth before I can judge. My immediate reaction is that it's not exactly what I was looking for. I'm looking more for something that works more like cmake's option() command for use in the user's jamfile, and set(... CACHE ....) for use in configuration-type libraries (such as jamplus' c/wxwidgets.jam). In other words, simple to use, and tailored to the build being performed. At the very least, the current values of all cacheable variables should be dumped into the cache, so the user can see what variables can be cached. Ideally, they would also include a documentation string (my simple module does not include that), and a way to query them before the initial run (impossible to do without major changes right now). One of the prerequisites of this behavior is that the cache cannot be created until the jamfile has been executed at least once. I don't think --workspace executes the jamfile at all (and probably can't, since it's executed using lua instead of jamplus).

The following generates the files for a proper out-of-tree build, although you may find that, at times, certain assumptions in Jamfiles need to be fixed up to make everything properly build out of source.

Yeah... again, I'll have to look at it a bit to figure out if it's what I was after. I would never have guessed that the --workspace option had to do with anything but IDEs. Of course it didn't help that workspace.sh wasn't installed by default, but strace told me what it was trying to do... I guess I'll have to report some of the build quirks I had to fix (linux x86-64) if I actually pursue using jamplus. In the mean time, I'll play with it a bit and comment later. One thing I will report right away is that you should use "$@" (with the quotes) instead of $* everywhere you use $* in shell scripts if you don't want people complaining about quoting issues later on.

As to the "certain assumptions", it would be nice if it were easier to figure out what those are. My current jamplus test won't even start to build out-of-tree without some changes. cmake provides default locations, and variables that give the precise location of each file. With jamplus, I had a hard time finding a file when I was trying to force the mpp module in luaplus to compile under Linux (in tree, not out-of-tree), but that's partially because I'm not that familiar with jam (last time I looked at it seriously was years ago, for much the same reason I'm looking at jamplus now, but back then it just wasn't worth it). I never did get the jam rule to work correctly (it tries to build one file every time, so I short-circuited it in the action), so I guess there are many things about jam that I just don't understand.

It has been a while since I used CMake. I would have to look into this feature to understand what it does. I'm curious if it can be simulated via the .config file settings described above.

It's just a one-time option to specify an initial include file. The option itself is silently saved to the cache, so it will always include that file again without having to use the cumbersome command-line. It's a somewhat special include file for cmake, because it's the only file that can be included before any library files. And yes, .config would take care of this requirement easily.

(1-2/2)