Hi, > > Updated the build system. Added a FindJansson and FindSlp module and > adjusted the bundles using those libraries. >
Looks good, though I'd like to suggest to use the find_package in the CMakeLists file when needed. For example, for remote services the find_package is done in the overall CMakeLists file. It makes more sense to place the find_package in the correct subdirectory. If, for some reason, someone disables a certain subdirectory, the dependencies aren't needed anymore as well. Now they always have to be installed. This should probably also happen with several other libraries/find modules. For example APR_UTIL. Also I noticed you use find_package, whereas previously I always used Include(FindXX). I think it is better to use find_package. So this is something that can be updated as well. (find_package provides more configuration options, whereas include doesn't have any at all). > I noticed that "make install" install to unwanted files for bundles. I > will try to fix that the coming days. > Feel free to take a look at it, but be very careful changing stuff involved in installing. It is used to create the bundles. CMake's installation/packaging system (CPack) supports Components, this is used to group the correct files for one bundle. For each component a CMake/CPack installation config file is created. Calling CPack with on of these configs creates the bundle. See the Packaging.cmake for the macros. But using Makefiles, these components can't easily be provided, so when running a make install all files marked for installation are installed. All framework files are installed in the component "framework", so if it is possible to call the normal install command with a component (or overwrite it) this problem is solved. This can be done when executing the config file yourself, see [1], for Celix this would be: "cmake -DCOMPONENT=framework -P cmake_install.cmake". The "make install-fw" does almost the same, but packages the files in a zip file, this can easily be changed to install the files in the file system. This is also a reason why I'd like to split the build into several projects. The framework/utils and launcher are normal plain old libraries, which could (should?) be installed like any other system library/executable. All bundles are more specific, and related to a certain deployment. So a "normal" installation makes less sense in that case. With several projects, the normal make install would work again. So as mentioned before, tread lightly when trying to do something about this... Though a solution would be really great! Another interesting thread is: [2] [1]: http://www.cmake.org/pipermail/cmake/2012-May/050465.html [2]: http://www.cmake.org/pipermail/cmake/2007-July/015305.html 2) IMO The Apache Celix binary, library and util library should be > renamed. The names are now bin/launcher, lib/libframework.so and > lib/libutils.so. I think these names are to generic and will bring > confusing. Any thoughts ? > Agreed. How about: launcher -> celix libframework -> libcelix_framework libutils -> libcelix_utils lib{anythingelsewecomeupwith -> libcelix_{anythingelsewecomeupwith} For the include files I'd like to use /prefix_to_include/celix/*.h instead of the header files directly in the include directory. This only applies to the system libraries, and not to the bundles. -- Met vriendelijke groet, Alexander Broekhuis
