cargo-c: improve install path conventions

[tmatth]

When installing the gst-plugin-rtp plugin from https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs, I noticed that with:
cargo cinstall -p gst-plugin-rtp --prefix=/usr/local

the rust plugins (the shared libs) install to /usr/local/lib/gstreamer-1.0/libgstrsrtp.so

whereas other gstreamer packages install to e.g., /usr/local/lib/x86_64-linux-gnu/gstreamer-1.0/

For now I can workaround this by explicitly adding --libdir=${PREFIX}/lib/x86_64-linux-gnu but it'd be preferable for this to follow the meson + autotools conventions (at least as I understand them).

@sdroege's comment:

there's probably some useful heuristic to detect lib, lib32, lib64, lib/target-triple

[lu-zero]

The normal libdir IS /usr/local/lib, adding a quasi-chost is a distribution-specific choice and I'm not aware of ways to know which it is which short of checking how they patched the rest of the toolchain.

See autotools docs.

If meson has some heuristic it is not exactly clear in that document, but if it works well enough there we can match it as long somebody provides a patch.

I'd avoid distro-specific logic though.

[sdroege]

If meson has some heuristic it is not exactly clear in that document

That seems like a question for @nirbheek

[eli-schwartz]

meson detects the operating system, and for Debian-like systems it executes dpkg-architecture -qDEB_HOST_MULTIARCH. Elsewhere, it checks whether lib64 is its own thing and not just a compat symlink. There are some other relevant heuristics as well. Check out mesonbuild.utils.universal.default_libdir().

Unlike autotools, the rough heuristic is "we try to do what's actually correct on your OS, if we do not know then we can always just default to /usr/local/lib instead, but let's try to actually be correct if we can".

It's not precisely a moving target, but it's definitely one where the code evolves. We got Haiku patches recently, for example.

[lu-zero]

Sounds like a fair amount of code who's willing to look into porting it? I wonder if would make sense making a separate crate for it.

[lu-zero]

@eli-schwartz can you link the meson heuristics? Probably it could be distilled in a stand alone crate so other tools may use it for the same purpose.

[nirbheek]

https://github.com/mesonbuild/meson/blob/master/mesonbuild/utils/universal.py#L1021-L1094

It's really quite simple, not worth putting it into a crate yet, IMO. Maybe you'd like to keep it as an internal module till it grows enough and then it can be split out?

[lu-zero]

If you have a timeslice to convert to a patch and send it would be great since I have plans to make a release soon due cbindgen ^^;