install: Clean up GNUInstallDirs usage of new install(TARGETS) default-destination behavior
Continuing discussion from !2558 (merged).
The new default-destination behavior of install(TARGETS)
is designed to make the installation process as frictionless as possible for the developer. When I was writing this feature, I decided that requiring GNUInstallDirs
to be included was too much friction for a first-time developer who wants to "do the right thing". The point of this feature is to allow the developer to say "I don't care, I don't want to think about it, just put everything in the right place", and have that work in all of the simple cases.
This does come at the slight expense of the package maintainer, who has to manually define the cache variables to comply with their own distribution's policies. I decided that this was OK, with the rationale that the package maintainer should always be setting these variables anyway, and some tools like Debhelper already do so automatically, so it shouldn't be a problem. However, it was pointed out that this still makes things more difficult for people who want to do local installations without building a formal distribution package.
There are a couple ways we could reconcile this:
- Require
GNUInstallDirs
to be included by:- Recommending in the documentation that the developer include
GNUInstallDirs
before running an install rule with this new default-destination behavior, and/or - Issuing an error (or a warning) if the default-destination behavior is invoked without
GNUInstallDirs
being loaded,
- Recommending in the documentation that the developer include
- Automatically and implicitly load
GNUInstallDirs
if the default-destination behavior is invoked, or - Leave the behavior as it is.
Options 1 creates more friction for the developer, but reduce it for the downstream maintainer. Option 2 reduces friction for both the developer and the downstream maintainer, but I'm not sure if I'm comfortable with implicitly loading GNUInstallDirs
. Option 3 creates friction for the downstream maintainer but not the developer.
This issue is to continue the above discussion.