Mailinglist Archive: opensuse-mingw (38 mails)

[Maarten Bosmans <mkbosmans@xxxxxxxxx>]

2011/4/20 Fridrich Strba <fridrich.strba@xxxxxxxxxx>:
> Hello, good people,
>
> On 06/04/2011 07:35, Fridrich Strba wrote:
> > As I understand the PKG_CONFIG_LIBDIR, once it is set, the
> > PKG_CONFIG_PATH is completely ignored. That is why I created that
> > mingw32-cross-pkg-config. Certain packages look for some build tools
> > using the native linux pc files. In that case, using
> > mingw32-cross-pkg-config and appropriate PKG_CONFIG_PATH is good.
> > I know that Fedora went the PKG_CONFIG_LIBDIR path long after we had the
> > mingw32-cross-pkg-config, but I am still considering that our solution
> > is more flexible.
>
> And this flexibility was useful in what I'm gonna describe.
>
> Some weeks ago I got bitten by a broken behaviour of the PKG_CHECK_MODULES
> macro. If some of the requested *.pc files, it will shout loud and it is
> good so. But if all the requested *.pc files are present, but some of the
> dependent *.pc files are not, the macro will still succeed checking for the
> packages, just will leave blank the corresponding *_CFLAGS and *_LIBS. And
> the logs are not really useful. One has to actually try to run the
> pkg-config command manually to get an error that is giving the right hint.
>
> So, having been bitten by this, I gave a thought to a more intelligent way
> of generating provides and dependencies also for the *-devel packages.

That's great. And thanks for the extensive explanation of how it works.

> The system that I implemented uses quite extensively
> mingw{32,64}-cross-pkg-config. There is still need to set the requires
> manually for packages that have nothing to do with pkg-config, but they are
> the minority and the dependencies in them are generally tried and true since
> some time.
>
> Now, how it works:
>
> Provides:
> In the mingw{32,64}-find-provides.sh we scan for
>        1) all *.a files
>        2) all *.pc files
> For each lib<libname>.dll.a or lib<libname>.a, we generate a provide
> mingw32(lib:<libname>)
> For each *.pc file, we ask mingw32-cross-pkg-config to --print-provides and
> we generate for each of them the mingw32(pkg:<pkgname>) = <version>. (And
> here it was great to be able to have default pkg-config path in our sys-root
> but also to add arbitrary directory to it).
>
> Requires:
> Those are purely done by the mingw32-cross-pkg-config. We querry each *.pc
> file for --print-requires and generate the require
> mingw32(pkg:<packagename>) for each of them, also being able to specify
> version requirements if they exist in the *.pc file.
> We also querry the *.pc files for --libs-only-l and for each -l<libname>, we
> generate mingw32(lib:<libname>) require.

Shouldn't it also check --print-requires-private? I don't know what
the difference is supposed to be for public and private dependencies,
but at least for cairo, pixman is not in the public dependencies of
any of the cairo*.pc files. Currently pixman is in the Requires: list
of cairo-devel. May be that's not needed though, in any case it isn't
needed for linking against Cairo.

> In this way, the *-devel package will be able to know all other *-devel
> packages needed for the correct function of PKG_CHECK_MODULES and all
> libraries neede for a proper -no-undefined linking.
>
> There inconvenient is that if a package distributes a *.pc file, it will
> have to buildrequire the mingw32-cross-pkg-config, even though the package
> itself does not "use" pkg-config for detecting its dependencies.
>
> The positive side is that we diminish a risk of mess in dependencies, and
> basically, one could eventually get rid of the manual dependency
> specifications in the *-devel files.

Have you tested this on some packages and did the new dependencies
pull in the same packages as the manual Requires tags?

> Another positive element is that the dependencies are not specified using
> the name of the package, but its content. This would eventually allow to
> have a little bit easier repackaging in case we decide one day to generate
> packages for other Windows package management systems.
>
> Don't hesitate to comment and to seek clarification if needed.
>
> Fridrich

Maarten
--
To unsubscribe, e-mail: opensuse-mingw+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-mingw+help@xxxxxxxxxxxx