CMake update 3/3: provide install target

[lubgr]

Follow-up CMake PR that fleshes out install targets. In short, this enables the following:

mkdir build && cd build
cmake -G Ninja path/to/chibi-source
ninja
ninja chibi-images meta-lists # not built by default
ninja install

will build shared libraries, the three image dumps and package metadata, and install it into /usr/local. The install path can be changed with cmake -D CMAKE_INSTALL_PREFIX=/my/custom/path, which will in turn show up in the install.h search paths (Unix platforms only, it's empty on Windows).

There is some additional plumbing to ensure that the installation works well with CMake projects using chibi. Given a CMake-configured chibi installation under a standard Unix path like /usr or /usr/local (other paths work when passing cmake -D CMAKE_PREFIX_PATH=/non/standard), the following sets up an embedding application:

add_executable(my_great_app main.cpp)

find_package(chibi-scheme 0.10.0 REQUIRED)

target_link_libraries(my_great_app
  PRIVATE
  chibi::libchibi-scheme)

All necessary linker and preprocessor flags will automatically be configured, and it works with a shared or a static library build/installation.

As an aside, I compared the current make install result to the result from the CMake-configured installation (mainly by means of tree), which raised the following questions:

• The Makefile seems to install many *-test.sld files. Is that intended?
• The srfi-18 threads shared library is installed twice, under srfi/18 and chibi/, why is that?
• lib/scheme/mapping/hash.sld and lib/srfi/160/uvector.scm are currently not installed, is this intended?

Also:

• Are image dumps supposed to work with static chibi builds? I haven't really investigated, but it seems that a static chibi executable doesn't generate any images.

Lastly, the following PRs might make sense if that's desired from your point of view.

• Update the docs (happy to do this, but I do appreciate if it's not desired as make is the standard build tooling)
• CI integration

[okuoku]

re: chibi-images target,

1. Why it's not in ALL dependency? In the original Makefile, which is part of install target and we should recreate the behaviour where possible.
2. Are we still okay not to override LD_LIBRARY_PATH or DYLD_LIBRARY_PATH unlike Makefile?

Same goes meta-list target; perhaps it could be a POST_BUILD custom target of chibi-images.

[lubgr]

Are we still okay not to override LD_LIBRARY_PATH or DYLD_LIBRARY_PATH unlike Makefile?

Yes, that's ok. When linking dynamically, CMake always uses the rpath mechanism. In the build tree, the rpath points to the correct locations within the build. Linked libraries are hence found and preferred over identically named libs in globally accessible paths (/usr/lib etc.). Only when installing targets, CMake automatically empties the rpath. Then finding the libraries relies on standard paths.

Why it's not in ALL dependency? In the original Makefile, which is part of install target and we should recreate the behaviour where possible.

I agree, the behaviour should be identical where possible. Not sure whether it is, in this case; CMake doesn't allow dependencies on the install target AFAIK. And adding the custom targets to ALL won't get the dependencies right; currently, they would be rebuilt every time (and we don't want to wait for generating the images on every incremental build). Maybe this can be fixed somehow, let me know if you have any ideas!

[okuoku]

Not sure whether it is, in this case; CMake doesn't allow dependencies on the install target AFAIK.

CMake can execute script fragment with CODE option of install but in general, everything should be generated in build-time; this custom target can be add_custom_command(OUTPUT) (and add these outputs into install command) anyway.

EDIT(PSA): You'll still need add_custom_target(ALL DEPENDS ...) to drive add_custom_command rule(s)

[lubgr]

Good suggestion, I did it as proposed and I think it's much better like this. Images and .meta lists are automatically built with the default ALL target. I had to add a new empty target for a shared library configuration that "collects" all compiled shared modules; otherwise the image generation didn't take them into account and could fail when a parallel build (ninja or make -j16 etc.) finished libchibi-scheme and chibi-scheme, but not the compiled libs, yet already started the image generation. If you know a better solution for this than the helper target, let me know.

[lubgr]

It seems image creation doesn't work on Windows, right? It requires the time module, but that's on the Windows exclusion list of compiled libraries. I'll opt out of image generation on Windows + static builds (kind of the same, because we only build static libraries on Windows).

[okuoku]

It seems image creation doesn't work on Windows, right? It requires the time module, but that's on the Windows exclusion list of compiled libraries.

Yep, unfortunately, not yet.

[okuoku]

@ashinn : It's ready to roll.

Future work: I think we should have several build modes on build. e.g.

1. Tool mode : Default(except Win32), install to /usr/local etc and honor it as default loading path.
2. Prefix-free tool mode : Win32 or using chibi-scheme during build process of other apps (only). Use relative path from the executable as default loading path. Maybe also useful on platforms we cannot control install path such as Android or iOS.
3. Embedded mode : Embed chibi-scheme program inside application w/ users application image(.img and .meta).

In other Schemes, NMosh and Sagittarius support 1 and 2 implicitly. Gauche showed interested in mode 3 before but I'm not sure it's current status.

[okuoku]

@ashinn : Friendly ping; are we okay to merge this? Changes do not affect standard Makefile build.

[ashinn]

@okuoku, sorry for the delay, yes this looks good to merge. The future work sounds reasonable as well.

Regarding better Windows support, while I can't hack on this directly, if you have refactorings or feature requests which would make that easier feel free to create tickets.

[okuoku]

@lubgr : Thank you for looking into cmake buildsystem. I might do some nitpicks for Windows later but anyway it's awesome having modernized CMakeLists.

(For future contributions, please consider building concise Git history -- fewer commits would be better. Since Git preserves complete history, we reviewers need to check every commits before merge. You can arrange Git history with git rebase -i etc.)

[lubgr]

Looking forward to seeing future improvements on the Windows side of things! I thought about having a look at how straightforward it might be to dynamically load .dlls by having a separate Windows-only LoadLibrary(...) path next to the dlopen option. I would have to setup a Windows system first, however, so this won't be now. Anyway, thanks for the review again, this was helpful!

For future contributions, please consider building concise Git history -- fewer commits would be better.

Will do!