Can cmake configuration files also be used to automatically extend the system PATH variable to include the directory paths to all the installed executable applications and if it is possible (and a standard practice), how can I do this?
This way, as soon as I configure all the CMakeLists.txt files and everything compiles (and hopefully runs) nicely, I can start using the applications, and the path configuration would be packaged together with the build process. I am working with Linux and my code is written in C++, but since cmake is cross-platform, the question extends to other systems as well.
I'm unaware of any capability in CMake to do this. However, we based what we do what Cantera does. They upgraded to SCONS recently instead of their old build system, but the idea still applies.
Anyway, there's a script that CMake configures with the paths during the configure step and then installs somewhere. So once built on Linux, one would run make install then source ~/setup_cantera and it sets up all the variables needed.
We do the same thing for our libraries built with CMake. It's possible to detect which shell the user is running and configure an appropriate template script.
Related
I am trying to build the latest GNURadio package on my development system. Unfortunately this system configuration is tightly controlled and I can't just install new packages of software on it as it is used to develop a product and all development systems are kept in lockstep. We are currently on an older version of RedHat.
While I cannot modify the system includes I can download and use newer versions of packages locally (in non-system directories) as long as that doesn't affect the product build/debug environment. Normally this isn't a problem.
However, when building GNURadio I found that our development platforms use an older version of the Boost libraries than is required to build GNURadio. So, I got the latest version of Boost and extracted it into my local (home) directory. I found several directions for, I thought, instructing CMake to use additional include directories. Unfortunately, this hasn't seemed to work with the Boost libraries. CMake keeps complaining that it finds the older version of Boost and not the newer one I have extracted locally.
I have tried using
-DCMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES=<dir>
and
-DCMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES_BEFORE=<dir>
and this had no effect. I then tried adding the following to the top-level CMakeLists.txt file:
SET(CMAKE_INCLUDE_DIRECTORIES_BEFORE ON)
SET(CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES <dir>)
or, even
include_directories(BEFORE <dir>)
Again, no joy.
I did a bit of digging and found that there is a GrBoost.cmake module and it had an additional configuration for the boost directory so I added this:
list(PREPEND BOOST_LIBRARYDIR "<dir>")
to the top of the file. Again, no luck.
I've never used CMake before (and I'm not really keen on learning yet another build system if I don't have to - our company just switched to bazel and I am coming up to speed on that) so I am flying blind here.
What do I have to do to get CMake to look in my local directory to find the Boost stuff I downloaded?
Ok. As it often happens, just after asking the question I was able to find an answer.
It turns out that there is a command-line option to CMake (CMAKE_PREFIX_PATH=<dir>) where you can specify additional base paths to search for CMake config files. I just added this to the command-line and it was found just fine.
I wasn't even aware that Boost came with such config files. Live and learn.
#vre's comment would have probably worked just as well (maybe better, in fact).
I have an embedded project for ARM platform, specifically aarch64.
Up until now I was using Make. I recently set up CMake with no particular issues.
I moved to CMake because I was under the impression it was a more modern build tool that would have allowed a smarter configuration.
For example, I can compile my project using different toolchains (aarch64-elf-gcc-linaro, aarch64-linux-gnu-gcc,...) and I would like CMake to try if any of those are installed on the system and use whichever is found first by default.
Is this possible (or meant to)? I'd expect it to be an easy feat for the tool, but after searching for a while I can't seem to find the right track.
Yes, you can make your CMake project to search for available tool-chains installed in your OS, choose one and compile your project. I also write a CMake program for ARM embedded project, because now it is universal transferable between different OS system Windows and Unix. On Linux there is ARM ToolChain installed and on Windows there is Keil-MDK. If you have different tool-chains to choose between, you can write CMake script which will find paths with command like find_path() and then call correct "toolchianxx.cmake" script with right compiler flags for chosen compiler.
In your particular problem just use find_path commands and use hits to find installed compilers in "pre-set" known paths.
It's said that library authors should ship their library with a config-file instead of a plain find-module.
Basically config-file are to be installed with the associated library on the system and can be used transparently by the user, whereas find-module is written by the user by his own when he finds out that the library hasn't any config-file.
But, what if I'm sure that my library will never be installed?
I'm doing embedded system development and it doesn't make much sense to install my static libraries on the system.
Different modules are organized as static libraries and handled by each project with git submodules.
Is there any way I can use config-files even in this scenario? Or, as library author, I should write a example of vanilla Find-module and say to client code "Take and copy this to your CMAKE_MODULE_PATH"?
Or maybe just tell the client code cmake to call add_subdirectory?
Is it possible generate build systems on one platform for another using cmake? For example, and the case I'm most interested in, is it possible to generate a set of Visual Studio solution files, or mingw32-make Makefiles, or nmake files, for a project from Linux?
The intention is to make something analogous to what the make dist target produces in automake. However, I don't need it to do as much as make dist does, i.e. I just want to generate the solution files as though I'd run cmake in Windows.
Users can then build the package using the created build system on their own machines.
If it is possible, how do I do it? Cmake doesn’t report the Windows based generators as being available on Linux.
After further research I believe the answer to my question is no. The reason is that the makefiles and solution files etc. produced by cmake depend on cmake itself, the path to which is hard-coded into the files.
One solution for windows might be to bundle the cmake executable with your files and replace the definition of CMAKE_COMMAND (for instance) added to makefiles with the path to your bundled version of cmake somehow. This is just a suggestion though, I haven't tried or even researched it much. If you do, please post the process as a comment or answer here.
What I am looking for:
Download library
Extract It
Apply custom patch
Run configure
Run build command
What library I am trying to build are:
Openssl
Boost
Thrift
C-ares
Curl
Pcre
Nginx
ICU
JsonCPP
I think I can do these things using external module: http://cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject
But I have following question?
I have different type of build and with different directory. Is it
going to build all these library for every different target? If yes
it will be painful as all these library take one hour to build. Is
there a way I can control it and it only build it once. As library
remains same for all these targets.
On switching directory to different name. Cmake force everything to
be rebuild-ed. Will it be same for external library. If yes? How to
solve this problem. I don't want to rebuild the library if I am not
changing them and want to use them while switching to different
branches without building them.
Yes, you can use CMake's ExternalProject feature to accomplish what you want to do.
When using cross-compilation in combination with external projects, the source code will be built once for each toolchain. You could avoid rebuilds if you checked in the results of the build into a source-control system, and re-checked it out on each new person's machine, but I do not recommend this. Instead, have one of your "set up new computer" tasks actually be allowing the compilation to run overnight, which will also act as a test that the machine is actually usable. That set-up task can be launched by a system administrator prior to a new hire's arrival, or you can leave it to the new hire, as circumstances require.
I'm not completely certain what you are asking in your second question, but if the library is unchanged, CMake will detect that it is unchanged and not recompile it. Typically, the source code would be in a single directory tree: each compiled version would be built in a distinct location. Thus, developers can access any compiled version at any time just by switching directories. This is particularly helpful because it allows you to mount these directories over NFS to embedded hardware, et cetera.