cmake: don't hard-code absolute path name /etc #1558
Conversation
- this breaks packaging and installation into a prefix in general - there's a GNUInstallDirs variable for /etc, too Also, don't make this installation conditional on the existence of /etc. Whether or not that directory exists on a build system has no meaning for installation to a target system. This had a potential to break cross-compiling.
|
Okay, but like always, please target the |
oops, sorry, fixed
There's no harm in doing that; it's a single text file and it does not bring any extra dependencies. If there's a downstream package which does not like that file, they are free to not include it in a package. |
|
Okay but why remove the directory existence check? Because of cross-compilation? |
Yes, this is explained in the PR description and in the commit message. In fact, this isn't just about cross-compiling. If you have a build-time check like this, you're introducing a non-explicit dependency into your build process. This might be fine when building on a developer's laptop, but in any real, automated packaging solution, this implies a need for a "useless" build-time dependency on libpam, otherwise you have a risk of producing a non-complete package. |
|
Fine, I suppose. |
cmake: don't hard-code absolute path name
/etcGNUInstallDirsvariable for/etc, tooAlso, don't make this installation conditional on the existence of
/etc. Whether or not that directory exists on a build system has no meaning for installation to a target system. This had a potential to break cross-compiling.