Meson: artificial limitation of directories (forced to be in prefix)

[arekm]

meson artificially limits location of directories for example:
Meson encountered an error: The value of the 'sbindir' option is '/sbin' which must be a subdir of the prefix '/usr'. Note that if you pass a relative path, it is assumed to be a subdir of prefix.

The common configuration here is to specify exact destination for directories like:
--bindir=%{_bindir} \ --datadir=%{_datadir} \ --includedir=%{_includedir} \ --infodir=%{_infodir} \ --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} \ --localedir=%{_localedir} \ --localstatedir=%{_localstatedir} \ --mandir=%{_mandir} \ --prefix=%{_prefix} \ --sbindir=%{_sbindir} \ --sharedstatedir=%{_sharedstatedir} \ --sysconfdir=%{_sysconfdir} \

but sometimes it's desired to put one directory outside prefix for example
--prefix=/usr \ --bindir=/usr/bin \ --sbindir=/sbin \

That's the case where /usr is on separate partition, sbin tools are needed at boot, bin tools are additional utilities that are not required at boot and thus live in /usr.

Currently meson forbits such configuration which is a problem.
Workaround: mv files around after meson finishes installation. Ugly workaround.

Not sure what's the point of limiting flexibility. If none exists then please drop this check and allow such configuration to succeed.

[bluetech]

Generally I think this restriction is good to have.

meson excludes a few directories from this check: https://github.com/mesonbuild/meson/blob/7b9843da02acb6e37de17218748a9af8f472c8e5/mesonbuild/coredata.py#L369 it might make sense to add sbindir to the list.

[ghost]

Generally I think this restriction is good to have.

The problem is that in this case, meson would impose a specific worldview onto the user/downstream developer using meson.

As arekm showed, GNU Autoconfigure allows for this fine-tuning. We can of course argue about the merits, pros and cons of either approach, but GNU Autoconfigure provides more flexibility here WHEN needed, whereas this appears to not be the case for meson.

In general I believe that flexibility is better, but I can also understand restrictions coming from another point of view since it may lead to a more complex/complicated codebase.

What I disagree with is to limit the flexibility-discussion solely to the NAMES of directories alone, though, because users can already, at their own discretion, arbitrarily rename all directories anyway - so I really think that this is just an option for more flexibility, and from this point of view, I completely agree with arekm. But it's just my half 2 cc anyway on the general topic of directory names; often the "bin/" versus "sbin/" distinction does not even make any real sense either, IMO. :)

[bluetech]

You convinced me! I mean, DESTDIR should have some assurances, prefix maybenot so much.

Relevant issue https://github.com/mesonbuild/meson/issues/1299 and PR https://github.com/mesonbuild/meson/pull/1308 (I haven't read them).

[nirbheek]

The solution in such a case is to set the prefix as /. In Meson, the prefix is the path inside which everything else is installed. In the last release, setting prefix to / was inadvertently broken, but it has been fixed with https://github.com/mesonbuild/meson/pull/2674.

This restriction is on purpose, and is useful in many situations, see #1209 for why.

[arekm]

Setting prefix to / forces me to set every other possible path to something desired like /usr/share or /usr/lib64 etc which sucks badly especially I can not automate that (or is there a sane way to list all directories that can to be set in a project at build time? )

[nirbheek]

meson --help lists all the directories that can be set, and these are the same for all projects. Generally, if you're doing packaging you have a pre-defined list of xxxdirs that you use for Autotools. You can use the same here.

[jtojnar]

There are legitimate reasons for having multiple prefixes. To allow installing multiple versions of the same package, Nix uses different directories in /nix/store for each instance of a package. It also allows to split package into multiple outputs (directories), which makes it possible for binary packages not to depend on headers and other development files (they will be installed to a different prefix that will not be downloaded).

@nirbheek could you clarify why single prefix is on purpose, I do not see any explanation in #1209.

---

Trying to emulate multiple prefixes with --prefix=/ will fail when a project uses prefix option to install a file.

For example, systemd files need to go to lib/systemd directory in prefix, not libdir.

Some projects also do it for other reasons (e.g. https://github.com/elementary/greeter/blob/ae716eb3af636f7ea52da8f8ee40f569c6b1d20a/src/meson.build#L11), though, these should probably be fixed.

[nirbheek]

@nirbheek could you clarify why single prefix is on purpose,

The reason is because Meson allows passing either a path relative to the prefix or an absolute path for --bindir and friends. Inside the build file, get_option('bindir') will always return a path relative to the prefix because almost everyone assumes that everything is installed into a single prefix.

This behavior is impossible to adhere to if bindir can be outside of prefix.

For example, systemd files need to go to lib/systemd directory in prefix, not libdir.

How does NixOS handle that?

[jtojnar]

How does NixOS handle that?

We are patching meson to allow out-of-prefix paths:

https://github.com/NixOS/nixpkgs/blob/8bd8c09f98ece814185a0e9b0285ac3c5e51d062/pkgs/development/tools/build-managers/meson/allow-dirs-outside-of-prefix.patch

[nirbheek]

I meant, where does NixOS install systemd's unit files? It seems to me that on ordinary Linux systems, the installation path should be libdir/../lib

[jtojnar]

To $prefix/lib/systemd usually.

[orbea]

The reason is because Meson allows passing either a path relative to the prefix or an absolute path for --bindir and friends. Inside the build file, get_option('bindir') will always return a path relative to the prefix because almost everyone assumes that everything is installed into a single prefix.

This behavior is impossible to adhere to if bindir can be outside of prefix.

@nirbheek It should only return a path relative to prefix when bindir is unset or indeed a relative path. If a user sets it to a full path which starts with an explicit / it should just use that. I don't understand what the problem is...

[jtojnar]

Agreed. This is what CMake’s GNUInstallDirs module does.

We (Nixpkgs) have been patching Meson to allow this for ages and only encountered few projects where it caused breakage (they were concatenating a *dir variable to prefix instead of using join_paths or Meson’s pkgconfig module) and we fixed the issues upstream in the affected projects.

[Ericson2314]

Yes given a major distro like NixOS needs this, and given that it hasn't proved a problem in practice, I don't see why we don't just do this.

[nirbheek]

Why isn't Nix setting prefix to be /? It's part of Meson's API contract that bindir is inside prefix.

[jtojnar]

Because packages are not allowed to install to arbitrary paths in /, only into their own prefixes /nix/store/${hash}-${name}-${output}/. Each package’s prefixes contains the regular FHS-like tree and GNU directory flags are set appropriately.

I am aware that it is part of the API contract but contracts can change. Yes, it would be a backwards incompatible change but in practice, we have only encountered few breakages in Nixpkgs, one of the largest software repositories there is. And all of those breakages were just caused by not following best practices like joining paths with join_paths or using pkgconfig module.

There would not even be effect on users and we are more than willing to continue to work with upstream project to improve their Meson build files. Having this artificial limitation (that neither Autotools or CMake exhibit) relaxed would allow us to link to official Meson documentation as one more point.

Since it is an artificial limitation that fortunately almost no-one relies on, I see no reason to hold onto it when there are clearly use cases and a demand.

[orbea]

To be entirely blunt I still don't understand why this conversation needs to happen. This is just yet another example of meson doing things terribly wrong and making things harder for distro maintainers for no perceivable reason. Just fix it?

[mbakke]

@orbea there is no need to resort to insults. This is an honest design mistake that affects just a few distributions.

It's unfortunate that we are discussing this in a closed issue though. @nirbheek do you mind reopening this?

[Ericson2314]

I could reopen this, but I'll wait a bit first, as I think it would be better if @nirbheek or somebody no afiliated with one of the affected distros did.