I have a project that takes about 15 mins to build on Windows using the Intel fortran compiler. I have added the required files to create an Inno setup installer. Using the NMake Makefiles generator, building and running cpack from the build directory with the command line --config CPackConfig.cmake results in
where after the line CPack: - Run preinstall target for: MyProject there is a delay of 15 minutes while the whole project is silently rebuilt.
However, using the Visual Studio 15 2017 generator, building and running cpack I don’t get the CPack: - Run preinstall target for: line and the installer is created in the time it takes InnoSetup to run. Any suggestions as to what might be happening and/or how I can prevent the preinstall target being run?
There’s the install/fast rule in Makefiles generators. This basically just runs the install scripts without trying to bring the build up-to-date. I don’t know if Visual Studio generators make such a target; it may be useful and worth an issue.
That seems to be the opposite of what is happening. The NMake Makefiles generator causes CPack to run the preinstall target, which is presumably what is causing the rebuild, whilst the Visual Studio generator results in CPack creating the installer directly. Is there a way of forcing the install/fast rule?
CPack checks if the CMake generator has a preinstall target and drives it if so. Only Makefile generators have a preinstall target. It’s meant for re-linking binaries on platforms that support RPATH/RUNPATH fields, but using executable formats that CMake doesn’t know how to edit, in order to produce binaries with the install-tree runtime path values. VS generators don’t support targeting any such platforms and so do not have a preinstall target. The Ninja generator just never supported those platforms, and these days CMake knows how to edit both ELF and XCOFF formats.
If a build is up to date, the preinstall target should not cause a full rebuild. That’s something to track down locally.
The above seems to be the most comprehensive documentation of the “preinstall target” to date.
I wonder, however, why Make is building this target in an ELF context though it is meant for platforms using executable formats that CMake doesn’t know how to edit … whereas CMake knows how to edit ELF.
The Makefile generators’ preinstall target is a generic step they define. It happens to be used for the relinking on platforms that need it, but could conceivably be used for other things. At the time CPack asks if the CMake generator has a preinstall step, we don’t have the project’s code model loaded and so cannot know whether relinking is needed for the current platform or not. Therefore I don’t think we can optimize it out.
Is there a way of forcing the preinstall target to be up-to-date? My project is now taking 20 mins to build. It has 46 targets (using 900 odd source files), many of which are static libraries used by other targets, producing 100s of fortran modules. Whatever dependency analysis is going on it can’t untangle the build and something always gets recompiled when rebuilding after a successful build - bizarrely not necessarily the same files - triggering a full rebuild. Currently I’m not bothering with the build itself, just the preinstall target, but I miss the coloured scrolling progress of the build.
If make all has finished and an immediate make preinstall is building something, then something is wrong with the dependencies. Does make all followed by another make all rebuild things too?
The code in cpack that runs the preinstall build step is here. It currently has no option to show it on the terminal, but does capture and log the output to a file. If anyone is interested in adding a way to change that behavior, please open an issue to propose it.