Because I’m currently thinking to completely ignore the --prefix option to simplify the project and generated files. Issue is getting correct paths for those special cases of /etc, /var, lib and similar directories at the install phase.
Can someone please explain, when this option might be useful?
What would such project miss in CMake context without being able to specify installation prefix at the install phase?
You don’t get to “ignore” --install --prefix at the project level, it has nothing to do with the project really. It is a tool for packagers, the downstream users who are building the project for whatever purpose.
The project is only aware of the configure-time prefix, CMAKE_INSTALL_PREFIX, it has no ability to interact with a prefix given at install time.
The purpose of the option is simple, it allows the install to occur to an arbitrary location. This is necessary for most packaging workflows. Imagine you are producing a tarball of the installed project. You must run the project’s install command, then collect the files into the archive.
If you installed the project directly into the system’s root folder, /usr/bin, /usr/include, etc. it would be very difficult to collect only the files relevant to the project from those locations. The solution is to install the project to some arbitrary, temporary prefix, with --install --prefix, then archive the files which appear there.
Well behaved projects generally shouldn’t care about the install prefix at all, at configuration or install time. Paths should be made relative within the install tree, allowing the overall tree to be relocatable so long as its structure is preserved.
I see. Thanks for reminding me of packaging. And also Windows, where user (ideally) should be able to pick where to install some software. Ok. I’ll try to work with that somehow or at least have this in mind for the future. Issue is that there are a lot of C-based software out there where an install prefix is “hardcoded” in a configuration header, for example.