Thank you! This looks good, except that LIBEXECDIR seems to belong to the bin output.

This will generate even more warnings like the following for projects that do not use GNUInstallDirs:

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_INSTALL_INCLUDEDIR
    CMAKE_INSTALL_LIBDIR

This can be avoided by writing a file with

SET(CMAKE_INSTALL_MANDIR "/path/to/lib" CACHE PATH "")

and running cmake with -C that/file.

I followed the directories in

As for the warning, I think it might be useful to retain it. If we want to do something about it, I would prefer patching CMake to show a single warning, something like “Manually-specified variables CMAKE_INSTALL_* flags are commonly registered by GNUInstallDirs module but the project does not include it.” and try to push it upstream.

Should we change it there?

I guess so, since libexec is for binaries which are likely to depend on libraries, while libraries may not depend on the binaries; but @vcunat has moved libexec from bin to lib in 3ec413c seemingly intentionally.

As for the warning, I think it might be useful to retain it.

Why? So far it has been only distracting. With more variables we will turn blind to it.

I guess so, since libexec is for binaries which are likely to depend on libraries, while libraries may not depend on the binaries

I think udisks is an example of a library that depends on a daemon from libexec. libinput is another one that comes to mind, though there it might make sense to split it to yet another output (service, or daemon like dbus has).

Why? So far it has been only distracting. With more variables we will turn blind to it.

It can serve as a reminder to pester upstream about it.

OK, perhaps libexec should be left with lib.

It can serve as a reminder to pester upstream about it.

These warnings can hardly serve that purpose: before this discussion I had no idea that CMAKE_INSTALL_LIBDIR might indicate an omission upstream rather than, say, the fact that a package does not install libraries.

I have looked at google-gflags to check whether it would be appropriate to ask upstream to use GNUInstallDirs (maybe a bit, but I won't ask) and noticed that it generates more warnings:

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_C_COMPILER
    CMAKE_INSTALL_INCLUDEDIR
    CMAKE_INSTALL_LIBDIR
    CMAKE_POLICY_DEFAULT_CMP0025

The first is because it is a C++-only project.

Such warnings make it difficult to notice cmake flags in specific .nix files that need updating (and that should rather be treated as errors).

I mainly chose to put it here as meson does the same in its own setup hook. Also, with more and more build systems, multiple-outputs would explode.

Yeah that makes sense. Perhaps we should make these conditional on $outputs != "out"?

Perhaps we should make these conditional on $outputs != "out"?

That's an interesting idea! For the purpose of preventing breakage of packages that expect these variables to contain relative paths, it might be even better to individually compare them to $out to avoid setting them even in some multiple output derivations:

if [ "${!outputBin}" != "$out" ]; then
    …-DCMAKE_INSTALL_BINDIR=…
    …-DCMAKE_INSTALL_SBINDIR=…
fi
if [ "${!outputInclude} != $out" ]; …

For the purpose of preventing useless CMake warnings, it is better to save them to a CMake cache file rather than to pass them on the command line.

Breakage in zoneminder: #76855

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/could-weve-implemented-multi-output-packages-better/6597/2

If you find this pull request and think this broke your package, please fix the project upstream as described in https://github.com/jtojnar/cmake-snips#assuming-cmake_install_dir-is-relative-path