fish assumes CMAKE_INSTALL_DATADIR must be relative

[jpalus]

CMAKE_INSTALL_DATADIR can be both relative, in which case CMake will add CMAKE_INSTALL_PREFIX or absolute when prefix is not added. fish assumes only relative path can be passed and if absolute path is used pkgconfig file is broken with prefix added:

fish-shell/cmake/Install.cmake

Line 17 in b0dc72e

set(rel_datadir ${CMAKE_INSTALL_DATADIR})

fish-shell/fish.pc.in

Lines 1 to 2 in b0dc72e

	prefix=@prefix@
	datadir=${prefix}/@rel_datadir@

[faho]

And you noticed this because?

Having these technically wrong things is always nice, but I'd prefer to have a usecase. What were you trying to do?

What would your preferred fix be? Canonicalizing the path before using it? Erroring out if an absolute path is passed?

[jpalus]

In our RPM based Linux distribution %cmake macro is used as a standard way to configure CMake based projects in a consistent way. That includes common (absolute) paths like %{_bindir} or %{_datadir} which end up in CMAKE_INSTALL_BINDIR and CMAKE_INSTALL_DATADIR respectively. After switching from autotools based fish version to one using cmake exclusively we've observed this regression. Note that for the time being it is patched on our level with:

--- fish-3.3.1/cmake/Install.cmake.orig 2021-07-06 16:45:37.000000000 +0200
+++ fish-3.3.1/cmake/Install.cmake      2021-07-19 20:04:46.496541738 +0200
@@ -14,7 +14,11 @@
 set(sysconfdir ${CMAKE_INSTALL_SYSCONFDIR})
 set(mandir ${CMAKE_INSTALL_MANDIR})
 
-set(rel_datadir ${CMAKE_INSTALL_DATADIR})
+if(IS_ABSOLUTE ${CMAKE_INSTALL_DATADIR})
+  file(RELATIVE_PATH rel_datadir ${CMAKE_INSTALL_PREFIX} ${CMAKE_INSTALL_DATADIR})
+else()
+  set(rel_datadir ${CMAKE_INSTALL_DATADIR})
+endif()
 set(datadir ${CMAKE_INSTALL_FULL_DATADIR})
 
 set(docdir ${CMAKE_INSTALL_DOCDIR})

[faho]

Okay, so why do we not encounter the same issue in our spec file (I'm assuming, having never actually built an rpm)? Is it just because we've never tried an absolute path?

Why do y'all pass absolute paths here? I've never really seen anything other than paths relative to the prefix.

Note that for the time being it is patched on our level with:

Ah, I'm assuming that computes the relative path from the absolute one, so it can then later prepend the PREFIX. And you'd get a path like ../../foo if DATADIR was outside of PREFIX?

That should work. If you want to open a PR that'd be great. (in general I'd love it if distro maintainers tried to upstream their stuff earlier - I've had to do that myself for some other things)

@zanchey should probably weigh in on this.

[jpalus]

Okay, so why do we not encounter the same issue in our spec file (I'm assuming, having never actually built an rpm)? Is it just because we've never tried an absolute path?

Why do y'all pass absolute paths here? I've never really seen anything other than paths relative to the prefix.

I assume your spec file targets RH/Fedora where %cmake macro looks differently and does not specify CMAKE_INSTALL_DATADIR explicitly - only CMAKE_INSTALL_PREFIX is defined. That means CMAKE_INSTALL_DATADIR defaults to relative share. What that also means is that RH/Fedora do not respect user customization of %{_datadir} macro (or any other similar macro for bin/doc/include/etc) like in all other specs ie for software based on autotools. That's the inconsistency our distribution wants to avoid.

Ah, I'm assuming that computes the relative path from the absolute one, so it can then later prepend the PREFIX. And you'd get a path like ../../foo if DATADIR was outside of PREFIX?

Correct.

That should work. If you want to open a PR that'd be great. (in general I'd love it if distro maintainers tried to upstream their stuff earlier - I've had to do that myself for some other things)

#8151 opened with equivalent but more concise fix.

[zanchey]

Yes, I think it would be reasonable to take a patch. I'm not sure why anyone wants to do this but I'm sure there are reasons!