Hello, On Mon, Jan 23, 2017 at 1:10 PM, Yaakov Selkowitz <yselkowi@xxxxxxxxxx> wrote: > On 2017-01-14 06:45, Neal Gompa wrote: >> >> On Sat, Jan 14, 2017 at 7:10 AM, Pavel Raiskup <praiskup@xxxxxxxxxx> >> wrote: >>> >>> On Friday, January 13, 2017 1:18:34 PM CET Neal Gompa wrote: >>>> >>>> On Fri, Jan 13, 2017 at 12:20 PM, Pavel Raiskup <praiskup@xxxxxxxxxx> >>>> wrote: >>>>> >>>>> On Friday, January 13, 2017 5:54:41 PM CET Pavel Raiskup wrote: >>>>>> >>>>>> Doh I missed this. This is now approved due to "bootstrapping issue". >>>>>> So the >>>>>> way to use "old" pkgconfig is (in case of FTBFS)? >>>>> >>>>> >>>>> Reading again the proposal, there's compatibility layer -- but the old >>>>> implementation nowhere (Obsoleted)? >>>>> >>>>> The package is in Rawhide ~2weeks. What set of packages has been >>>>> rebuilt to >>>>> test for peculiarities? Who else (distros) did this change and why? >>>>> >>>>> Who pinged upstream of "old" pkgconfig (seems like the last release is >>>>> from >>>>> 2016, it is not dead). >>>>> >>>>> Why don't we have both implementations and let user's pick the >>>>> implementation they like? And resolve the "bootstrapping issue" with >>>>> the >>>>> implementation which better suits ...? >>>>> >>>> >>>> The pkgconf-pkg-config package has not been enabled yet. Once this >>>> change is accepted, I'll build to enable it, and the distribution will >>>> automatically prefer it over pkgconfig (since pkgconf-pkg-config >>>> provides a slightly higher version of pkgconfig and Conflicts with >>>> pkgconfig versions lower than what it provides for this purpose). >>>> After mass rebuild completes, pkgconfig can be retired from >>>> Rawhide/F26 and pkgconf-pkg-config can Obsolete it. >>> >>> >>> Sorry this doesn'ŧ answer my clear questions, still OK to answer them.. >>> >>> It looks like somebody needs to test some re-implementation of >>> pkg-congfig (and >>> I'm pretty sure Fedora Rawhide is not correct place to play such games). >>> I'm >>> curious how it is even possible that we in Fedora are able to do such >>> quick >>> decissions. >>> >> >> You and I have different views on what Fedora is about, clearly. And >> this is absolutely no game. That being said, pkgconf has been brutally >> tested by FreeBSD Ports and pkgsrc (BSD and Linux), where it has >> survived multiple mass rebuilds. GNOME already makes incompatibilities >> with pkgconf a blocker in their release strategy, and while pkgconf is >> fully conformant to the "specification" of .pc files, it already >> supports more of it than pkgconfig does. Admittedly, it is less >> tolerant of badly written .pc files, but those should be fixed, >> anyway. >> >> I am extremely confident that the change will be mostly (if not >> completely) transparent. > > > What about mingw-pkg-config? Using pkgconf for a cross-pkg-config is a bit > more work because of the library (in which the default search path is > hardcoded) would then need to be built statically into the binary, and > subsequently not installed so as to not conflict with the "native" > libpkgconf. > > That being said, I wonder if embedding the default search path into the > library isn't a mistake in design, as it does not prevent the need for > multiple copies of the same code as in the above example. Instead, if the > library were to be path agnostic and shipped separately, and the default > search paths set by the consumers, then a cross-pkgconf could use such a > libpkgconf. It is possible to override the default at runtime inside libpkgconf. The default is only used if you do not install a search path prior to calling pkgconf_pkg_dir_list_build(). An easier way is to use the PKG_CONFIG_LIBDIR and PKG_CONFIG_PATH environmental variables, which can be used by cross wrappers to completely replace the default. PKG_CONFIG_LIBDIR is the fallback paths, which PKG_CONFIG_PATH are the site paths. This approach also works with pkg-config but I don't know to what extent it is formally supported there. Feel free to drop by #pkgconf in freenode IRC if you have questions about it, I'm quite certain we can find a solution that will work for you. William _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
