pkgconfig: Add generator for -uninstalled.pc

[xclaesse]

GStreamer generates 2 different pc file, one that will be installed, and one that is not installed and used to build applications using GStreamer from a build dir instead of system's GStreamer. This seems to not be that uncommon usage since pkg-config itself has special code for handling -uninstalled.pc files, pkg-config glib-2.0 will prefer glib-2.0-uninstalled.pc if one is found in its search paths.

The big differences in an uninstalled pc file are:

• Cflags instead of having -I{includedir} has one -I per include directory in the source tree, like -I/path/to/src/liba/ -I/path/to/src/libb/. This can be generated automatically by meson.
• Libs instead of having -L${libdir} has the abs path where meson built the library. This can be generated automatically by meson.
• variables often contains paths relative to ${prefix}, user would need to provide different list of variables for the uninstalled pc file. For example GStreamer has pluginsdir=${libdir}/gstreamer-1.0 in the installed pc file, and pluginsdir=@abs_top_builddir@/plugins in the uninstalled pc file. That meson cannot know.

So, what about adding uninstalled : true and uninstalled_variables : [myvars] kwargs to also generate an uninstalled pc file.

[tp-m]

Another question is where the uninstalled pkg-config file should go. Currently the .pc files generated by this API go into the meson-private directory if I'm not mistaken, whereas before they went into the build dir requested (pkgconfig/ subdir in GStreamer's case). Not saying it can't be changed, just something that perhaps needs discussion.

Maybe the uninstalled bool kwarg is superfluous and specifying uninstalled_variables makes it happen?

[xclaesse]

Maybe the uninstalled bool kwarg is superfluous and specifying uninstalled_variables makes it happen?

Though about that, but what if you don't have variables to define? It's a bit weird to pass an empty array to enable a feature.

[jpakkane]

We really don't want to support people using stuff from the build dir directly because the files (especially shared libraries) are in a "special" state and we will not guarantee any sort of stability for stuff inside the build dir.

[xclaesse]

I was expecting that answer. I personally don't care about this, but it's blocking the patch to use meson pc generator for all .pc in GStreamer project.

@tp-m do you consider this as blocker for GStreamer, or we can just drop that "feature" ?

[tp-m]

As I mentioned on the GStreamer ticket, I am happy to drop it (and did so in the initial port) - it was someof your colleagues who added it back, so you'll have to convince them :)

[nirbheek]

We really don't want to support people using stuff from the build dir directly because the files (especially shared libraries) are in a "special" state and we will not guarantee any sort of stability for stuff inside the build dir.

I'm not sure what you mean by this, @jpakkane. The files in the builddir are in a special state because we want people to be able to use them as-is (for testing and development). Of course they shouldn't use those binaries in production, but *-uninstalled.pc is not for production use anyway.

[nirbheek]

Also note that foo-uninstalled.pc is not a gstreamer-specific feature. It's a pkg-config feature. When you search for foo.pc, it will first look for foo-uninstalled.pc in the specified PKG_CONFIG_PATH directories.

gstreamer uses this with the gst-uninstalled environment so that people can quickly build their projects against gstreamer's libraries while doing development.

[jpakkane]

The files in the builddir are in a special state because we want people to be able to use them as-is

Yes, for the very special use case we have of running them from where they currently lie. But the implementation of how that is done may change. As can pretty much anything else. If we expose the internal state to the outside world, we can never ever change it again because people will complain.

We can make it work in the case where we are in control of the entire pipeline. Any other use requires installation. If people want to dip inside the build dir, they are free to do that and then keep both pieces when it breaks.

[xclaesse]

If we change the layout of build dir, -uninstalled.pc will be updated too. Will only require a rebuild of apps using them which is not a big deal for a developer feature imo.

[jpakkane]

Even in that case that is extra maintenance work that someone will have to do. That someone is, in all likelyhood, me.

[tp-m]

It is well understood by everyone using this that -uninstalled.pc is a feature that will only work under certain conditions. I think it would be sufficient to just add a 'no guarantees, you get to keep the pieces, etc.' disclaimer to the kwarg that adds the generation of these files.

[nirbheek]

If we expose the internal state to the outside world, we can never ever change it again because people will complain.

I don't think we have to expose internal state; we can document that the -uninstalled files should be treated as a black-box by everyone (this is already how they are used; most people don't even know they exist or how they work).

Even in that case that is extra maintenance work that someone will have to do. That someone is, in all likelyhood, me.

Well, you're not the only one maintaining Meson, even though I understand that it must feel like that sometimes. I have noticed many problems with our contributor retention and how we encourage them to be more involved. I'd love to talk to you about that at GUADEC!

[xclaesse]

Even in that case that is extra maintenance work that someone will have to do. That someone is, in all likelyhood, me.

Yes, like every PR that gets merged. Should we stop merging code in meson so we don't have to maintain it anymore?

[xclaesse]

In recent discussion, I emitted the idea of having pkgconfig.generate() return an internal dependency object that can be used like this:

lib = library()
lib_dep = pkg.generate(lib)
app = executable('app', dependencies : lib_dep)

Thd use-case given on IRC by @wjt : libfoo is a library used to build a plugin. That libfoo comes with a .pc file that has a variable plugindir, so the project would build the plugin with:

dep = dependency('libfoo')
m = shared_module('myplugin',
  dependencies : dep,
  install_dir : dep.get_pkg_variable('plugindir')
)

But that won't work if libfoo dep is provided by a subproject fallback, because it won't have variables. This could be solved by having a InternalPkgConfigDependency object that wraps a -uninstalled.pc file. So there is a lot of overlap in those features.

[xclaesse]

That could also simplify a pattern I often see in many projects:

lib = library()
pkg.generate(lib)
lib_dep = declare_dependency(link_with:lib)

Becomes:

lib = library()
lib_dep = pkg.generate(lib)

[xclaesse]

Oh, and it would also cleanup the ugly generated_pc attr we set on SharedLibrary objects that we use to write Requires.private: instead of Libs.private: in pc files in that case:

lib1=library()
pkg.generate(lib1)
lib2=library(link_with:lib1)
pkg.generate(lib2)

[ebassi]

I'd like to add an opposing note: uninstalled pkg-config files are a relic of a bygone era, mostly used when building core libraries on platforms that didn't ship pkg-config and, instead, required building pkg-config in a separate prefix. From a historical perspective, the main consumer of uninstalled pkg-config files was Solaris, back in the early days of the transition from glib-config/gtk-config to pkg-config, and before we had tools like jhbuild to set up a proper development environment.

We've successfully removed most instances of uninstalled pkg-config files over the years, and I'm honestly surprised to learn that GStreamer still ships them.

[xclaesse]

@ebassi as far as I understand, it has nothing to do with old/weird platforms. It's a tool for devs to make easy to build against a library without installing it. For example if I write an app that needs GStreamer master, I can link against my build of GStreamer without the need of installing it into a prefix.

I personally don't use that feature, I prefer to install in a custom prefix (I do have custom scripts for that) but it seems many GStreamer devs are attached to that workflow, and it makes sense IMHO.

@tp-m correct me if I misunderstood.

[tp-m]

but it seems many GStreamer devs are attached to that workflow

It was used for the old autotools uninstalled dev environment.

I don't know if it's true that "many GStreamer devs are attached to that workflow" - it was one or two of your colleagues who were keen to maintain this when I suggested to remove it a while back. That was some time ago though, when Meson was less mature and less widely used and people were just starting with it, so this may have changed in the meantime.

I'm still happy to get rid of it and think we should simply not support this going forward.