I usually configurate and generate batch of projects with mostly all the same options. I observed that my configuration time was very long (several seconds) for each project.
Doing some profiling, I observed that all the time was taken by try_compile in check_ipo_supported.
Is there a way to safely gain some times (My expectation is that I could check for the first project, then tell the others that ipo is supported)?
Regards,
A.
[EDIT 1] a bit more details:
In practice, I’ve got a python script that is calling cmake <src dir> -B<build dir> <common options> for a set of projects (only <src dir> and <build dir> are changing from a project to the other).
If the first project to call check_ipo_supported reports a success, I’d like the other calls in the same run not to call check_ipo_supported again but I don’t know how to pass an information from a cmake call to another one.
I could make a fake top CMakeLists.txt containing only add_subdirectories(<src dir> <build dir>) and setting a shared CMake variable at the first call. I don’t know if its possible and, besides, I would prefer to avoid this extraneous CMakeLists.txt (besides I’m not sure about possible conflicts if I configure a project by itself or from the fake top project).
[EDIT 2] as a bonus, I would like to skip compiler detection also as it’s always the same after the first detection. But its less important as this step seems to be fast (at least much faster that IPO detection).
I tried to set an ENV variable at first call but its lifetime seems limited to the current CMake process, not the calling terminal. Still looking for a solution…
That’s just how environment variables work. You need strace or other debugging tools to change the environment of other (running) processes.
A 100% hack is that you could configure a project that enables the relevant compilers and then copy the CMakeFiles/CMAKE_VERSION directory. I don’t know if a new configure ends up ignoring this or not though. If that doesn’t work, I suggest generating a toolchain file from the first project and then using that to propagate memoized information to other builds.
Unfortunately I cannot test it due to the way I’m proceeding: before to launch a cmake configuration I’m looking into the cache to see if the compiler referenced in the cache is the same as requested at command line. If it’s not the case, I’m cleaning completely the CMake build directory and start configuration again.
I had to do like this because if I reconfigured an already configured project but changing compiler, it did not work properly (I can’t recall what was the exact issue).
I need to rethink my process if I want to test your solution…
Yet if I understand correctly, the correct way to go would be through a toolchain?
Just for information. With a quick and dirty workaround in my process. I tested the copy-past solution. At first glance it seems to work (and I see the time gained for configuration).