By analyzing the blame information on this pull request, we identified @vcunat, @urkud and @lethalman to be potential reviewers

Thanks, I ran into a similar issue just yesterday

What's the issue? Most probably this is i not the right fix, given glib never had to propagate pcre. What's the error specifically?

I will review if propagating is the right decision.

From (Compiling the GLib package: GLib Reference Manual)[https://developer.gnome.org/glib/stable/glib-building.html]:

GRegex uses the PCRE library for regular expression matching. The default is to use the internal version of PCRE that is patched to use GLib for memory management and Unicode handling. If you prefer to use the system-supplied PCRE library you can pass the --with-pcre=system option to, but it is not recommended

So it would probably be better to use the internal pcre version in the first place.

I tested GRegex without the propagated libpcre and it seemed to work.

What led me to believe propagation was required is the output of CMake when including glib-2.0:

Package libpcre was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpcre.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpcre', required by 'glib-2.0', not found

I'm absolutely clueless if this is a bug in autoconf/pkg-config (should ignore Requires.private completely when building shared?) or whether .pc files should be available even for private dependencies.

Any thoughts?

The fact is that for other distros it may be useful, but probably for nix it's not because of rpath. Maybe we should patch pkgconfig to ignore private libs for dynamic linking? @vcunat @edolstra

We already have a patch changing the private deps somehow, in pkgs/development/tools/misc/pkgconfig/requires-private.patch. I don't remember exact details. IIRC there wasn't broad consensus about the meaning of requires-private, so different packages expected different things from it...

But I wonder why we're having problems with it right now... what changed since few weeks? Glib obviously has always been linked to other programs with pkgconfig.
Perhaps pcre was included during the build processes everytime for some other reason? And now it's no more the case? I'd like to know the commit that changed this.

@lethalman The change was introduced in 6b8a8ca and merged with closure-size into master

I agree the changes are likely from closure-size merge – there were also later commits adding the pcre dependency back after "splitting" pcre.

@vcunat what about avoid touching pkgconfig and removing pcre from glib private require? It's clearly put by glib devs here https://github.com/GNOME/glib/blob/master/glib-2.0.pc.in but there's no need in nix because glib links directly to libpcre, and libpcre headers are not exposed.

IIRC *.private are only meant to be used when linking statically – that way you would need to link explicitly with anything glib uses, but we rarely use static linking.

From https://people.freedesktop.org/~dbn/pkg-config-guide.html:
"On the other hand, libraries from Requires.private will only be included when static linking."

Given pkg-config --libs doesn't show libpcre, I believe it's something wrong with the m4 of the configure stuff:

$ env|grep pcre
$ pkg-config --print-errors --cflags --libs glib-2.0
-I/nix/store/dpfrpllpqmw5b9pdhshj5g3hyikw3b79-glib-2.48.1-dev/include/glib-2.0 -I/nix/store/w15z2dphj6g1kij164i74c6mvwaykf0c-glib-2.48.1/lib/glib-2.0/include -L/nix/store/w15z2dphj6g1kij164i74c6mvwaykf0c-glib-2.48.1/lib -lglib-2.0

Ah looks like it only happens with cmake projects... like this: http://hydra.nixos.org/build/36252754/log/raw

And I think it's because of this line: https://github.com/Kitware/CMake/blob/d08281094948eaefb495040f4a7bb45cba17a5a7/Modules/FindPkgConfig.cmake#L119

Looks like pkg-config --static is invoked even when doing a dynamic only build. And using --static indeed results in an error about pcre.

So looks like if we ever want to support static linking we still need to use propagatedBuildInputs unfortunately.

Ah, apparently cmake always prepares variables for both cases. The PR will increase build-time closure, but I can't see a better solution ATM.

@vcunat shall this go to staging first?

Yes, better that way, I think.

If it's a cmake problem, wouldn't it be better to fix cmake? Propagated build inputs are not a good idea in general...

@edolstra it's not a problem. We need a policy about support for static builds. If you want to do a static build you need that pcre being propagated.

Well, it's true that first we would need pcre that creates static libraries. I think that's typically done with different compiler flags, so it would better be done in a separate build anyway.

Was there consensus on this? Looks to me like a different solution is preferred?

Last time nobody responded so closing this now.