Re: [Mingw-cross-env-list] Proposal: Cflags.private entry for pkg-config

[Volker Grabsch]

René Berber schrieb:
> On Wed, 28 Mar 2012 Volker Grabsch wrote:
> 
> >FYI: I just filed a feature request for Cflags.private in
> >pkg-config. Maybe this will simplify things for us in the
> >future:
> >
> >https://bugs.freedesktop.org/show_bug.cgi?id=47996
> >
> >Anyone interested in implementing that?
> 
> Since there is a --static option and corresponding Static spec for
> the .pc file, it follows...
> 
> Two points:
> 
> 1) Why is Static not being used for this?
> 
> Other than the obvious reason that nobody else seems to use it.

That's a perfectly valid reason.

The community of people who cross-compile their applications
to Windows is not that big. Most people use a native Windows
system, install VS Express, or use Cygwin.

Moreover, even those who do cross-compiling for Windows are
usually doing that "by hand", i.e. running ./configure, make,
by hand, fix issues as they appear by hand, and are so glad
it somehow works they document their work only superficially,
if at all.

To my knowledge, MXE is one of very few only projects that
value clean, reproducible cross-build for Windows. If you
don't have this aspiration (which is perfectly understanable
as it is a very nasty topic), you won't even think of using
pkg-config to configure your Windows cross-builds.

I'm not saying that nobody else is doing clean cross-builds
for Windows, just that it's very few people.

So we (the MXE project) are in a predestinated position of
fixing that.

> 2) Wouldn't this be useless in real practice (i.e. using those libraries)?
> 
> i.e. paraphrasing the definition "private X required by this package
> but not exposed to applications."  I think that the need to define
> something to create static libraries doesn't stop there, the same
> definition is needed when linking those static libraries to
> something else.
>
> Perhaps the word 'useless' is a bit hard, but many of the problem
> reports we see in this list stem from the need to use those flags,
> and that the flags are not easy to find.

That's where pkg-config steps in.

Whenever a library builds, it gets (probably via pkg-config,
or via some houristics) a full list of the required libraries.
This list just needs to be assembled and to be put into a
@VARIABLE@ which is then used in Libs.private.

Many packages show that this can be done with a little effort.
Moreover, any library that wants to be linked statically
(no matter whether native or cross builds) has to do this.
And many do.

That's about Libs.private. However, Cflags.private is a
different beast. That's only necessary when using pkg-config
for Windows builds. Moreover, it's only needed for _static_
Windows builds. Since most projects aren't aware of the fact
that pkg-config is really, really handy for Windows cross-
builds, they don't care about Cflags.private, but I'm sure
they will accept patches about it.

> My own recent experience: I'm thinking of sending c-ares.mk to this
> project, but to use it (other than in curl which already knows how
> to use it) the .pc file needs to be patched because there is no
> Static spec on the original, and for static linking its useless w/o
> the -DCARES_STATICLIB, and to find that little tidbit you have to
> look into ares.h since its not documented anywhere else.

Maybe I'm misunderstanding something here, but:

So what?

Okay, the upstream project should provide Libs.private, but
if they don't, we just patch those in. The cleaner way would
be to fix the build system and supply that patch to them.
But as long as nobody does this work, a well-documented
fix, shared with others (i.e. other users of MXE), is a
lot better than always working around it by hand.

And the same holds for -DCARES_STATICLIB. Of course it would
be cleaner if pkg-config would support Cflags.private, but
as long as it doesn't, we simply patch that into Cflags.
Or, if that doesn't work for some reason, this has to be
added by hand to any package depending on c-ares.

That's not perfectly clean, but not a show-stopper, either.

Since cross-compiling for Windows _is_ nasty, we do have
to use nasty hacks from time to time. But we also replace
this nasty stuff with cleaner solutions, step by step,
until we have something that's accepted by upstream. This
approach is not perfect, but works quite well.


Regards,
Volker

-- 
Volker Grabsch
---<<(())>>---