What's up with the list?

[Erik de Castro Lopo]

Matěj Týč wrote:

> > Specifically, you have to show at least one case where you need a
> > separate CPPFLAGS or CXXFLAGS where the same result can't be achieved
> > with CFLAGS.
> 1. CXXFLAGS x CFLAGS: You have a project with C++ source and C source
> (this is one of the reasons why wxWidgets don't use pkg-config)

You still haven't told us specifically, what exactly the problem
is.

> 2. CPPFLAGS x other ones: Supporting this is a matter of standards.
> Somebody else probably knows better than me, for instance Bernd
> Petrovitsch (see his post from 10.Oct.)

If it isn't broken don't fix it.

> For most people it is enough for sure, but again, it is more a question
> of standards

If it isn't broken don't fix it.

> > > I would like pkg-config to produce <host>-pkg-config executable so that
> > > the user doesn't have to do it for himself.
> >
> > For which <host>? Are you really suggesting that the pkgconfig 
> > package supply scripts for 100 different cross compilers? What
> > about people who never use cross compilers? They don't want those
> > hundreds of scripts.
>
> I meant the name of pkg-config that you compile from source on your
> platform.

The native pkg-config for the host should just be called pkg-config
and it will be used quite happily for all native builds.

For cross compiling you, the user, create a XXXX-pkg-config
wrapper script for every cross compiler you use and stick them
somewhere on your path. The wrapper sets up a few environement
variables and then calls the native pkg-config so that it now
acts in a manner specified by the environment variables.

> Then, if you want to cross compile with pkg-config,
> you cross compile it and you get <host>-pkg-config in the host
> $prefix/bin directory etc.

Why? When you are cross compiling $prefix/bin is where your
cross compiled binaries go. In most cases cross compiled 
binaries will not work on the host you are compiling on.

> I like this idea, I still can't see what's wrong with it.

If you have just cross compiled a wince-arm-pkg-config on an
i386 Linux host, that wince-arm-pkg-config binary will not run on
your Linux host.

> pkg-config is, unfortunatelly, not a standard cross compiler tool.

Neither is Make. So what?

> I
> meant that you have to cross compile it first before you use it.

You only need to cross compile pkg-config if you want a native
pkg-config binary that runs on your cross compile target platform.

However, if you are mainly cross compiling why would you want that?

> Then it is in that host $prefix/bin directory

But for the *VAST* majority of cross compiler host/target pairs,
the cross compiled pkg-coinfig binary will not run on the host
system.

> It is better to fix it in one place than to make everybody who wants to
> cross compile to fix it for himself.

Each developer that has set up a cross compiler tool chain has
probably put those tools in a separate place. Some would have them
in /usr, some in /usr/local, some in /opt and some in their home
directories.

That is why everyone needs to set up their own wrapper script and
that fixing it in one place won't help the vast majority.

> Without any official guide.

So document it and submit a patch for the pkg-config docs.

> Some people (not only me) do and they can name several different reasons
> for that.

You still haven't come up with one concrete problem that cannot
be fixed in a totally satisfatory way in 10 minutes.

> Is there any interest in improving pkg-config?

You haven't come up with a single concrete suggestion for an
improvement that actually looks like an improvement.

Furthermore, if the problems with pkg-config were as big as you
claim then there would be lots of people on the list making the
same complaints.

So, at the moment its just you and me on this list. I feel that I
am not getting my point across or that you are simply not getting
my point and we're not making any progress on this issue. I feel
I'm wasting my time. I am therefore unlikely to add anything more
to this thread.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"If you are going to SCO to license superior driver technology,
 you need to reevaluate your product."
  -- Comment about SUN and SCO on Linuxtoday.com