support absolute directories in ADM_INSTALL_*

[tomjnixon]

Since 56e7bc512823eb83b8ad48c24cbd3c41e817f4b0, the CMAKEINSTALL variables are used to set the install paths, however these are allowed to be absolute paths, and this causes libadm_DIRS to be set incorrectly (to two concatenated absolute paths).

Fix this behaviour using GNUInstallDirs_get_absolute_install_dir, which gives the same behaviour as just using CMAKEINSTALL* dirs directly.

This is useful mainly for split distribution packaging, where development and run-time components are installed to completely separate output directories

[rsjbailey]

I guess the issue with this (and if you pass absolute files into CMAKE_ variables in general), is that you'll wind up with hard coded paths in your exported targets, which may or may not matter depending on your platform.

I'm guessing if you're deliberately messing with those vars to pass in absolute directories you're probably fine with that though?

I think another way to do this might be to split development/runtime artifacts into separate COMPONENTs via the install command, then just run the installer twice when doing packaging

so

install(DIRECTORY ${PROJECT_SOURCE_DIR}/include/
          DESTINATION ${ADM_INSTALL_INCLUDE_DIR}
          PATTERN "private*" EXCLUDE
          COMPONENT DEV
  )

install(TARGETS adm
      EXPORT admTargetsShared
      LIBRARY DESTINATION "${ADM_INSTALL_LIB_DIR}"
      RUNTIME DESTINATION "${ADM_INSTALL_BIN_DIR}"
      ARCHIVE DESTINATION "${ADM_INSTALL_LIB_DIR}"
      COMPONENT RUN_TIME
    )

cmake --install --component DEV --prefix /some/prefix
cmake --install --component RUN_TIME --prefix /some/other/prefix

[tomjnixon]

I guess the issue with this (and if you pass absolute files into CMAKE_ variables in general), is that you'll wind up with hard coded paths in your exported targets, which may or may not matter depending on your platform.

Yeah, i don't know if this is something that's expected to work? I thought most distribution packaging would set the ultimate destination using CMAKE_INSTALL_PREFIX, then use DESTDIR to install it into a different staging area.

Trying out, it looks like it would work if not for this change, so breaking that is possibly bad. Some ways around this would be:

• don't set libadm_INCLUDE_DIRS and just use targets? I guess we just set these directories for compatibility, but maybe that's not necessary?
• compute the absolute path in config.in (using path)
• compute the relative path between PACKAGE_PREFIX_DIR and ADM_INSTALLFULL* outside of Config.in, and concatenate them in Config.in
• leave it as is and i can work around it

The second option is easy to do -- that's what i started with. Originally i thought that this would ignore the special cases in GNUInstallDirs, but it looks like the only relevant one (the first) is already applied to ADMINSTALL* vars, so it would be fine.

I'm guessing if you're deliberately messing with those vars to pass in absolute directories you're probably fine with that though?

Yeah exactly. This just gets you the same behavior as a regular GNUInstallDirs user -- the current behavior is mostly the same except for a few edge cases that most people will not hit.

My specific reason for wanting this is using it in nix, which wants things installed into absolute paths. You can definitely work around this issue (by just specifying the prefix or spiting it up as you suggest), but the default recipe just works for packages that use GNUInstallDirs in the expected ways.

Sorry this is a bit more complicated than i expected!

[tomjnixon]

Updated to use cmake_path instead, which should be as re-locatable as the previous method.

I've tested this by installing it to a local directory with CMAKE_INSTALL_PREFIX then picking this up with another project that used libadm, and my nix-based build.

[tomjnixon]

Third time lucky -- the latest version just removes these variables, because they were misnamed and should not be used anyway.

[rsjbailey]

Looks good to me.

[tomjnixon]

Thanks!