Re: lua.pc pkg-config file

[William Ahern <william@...>]

On Thu, Mar 26, 2015 at 11:24:05AM +0100, Nicola Fontana wrote:
> Il Wed, 25 Mar 2015 16:08:53 -0700 William Ahern <william@25thandClement.com> scrisse:
> 
> > It sucks that people are relying on pkg-config so much.
> 
> I disagree with almost anything you wrote but on this I disagree more.
> 
> pkg-config is just a piece of C code (just like Lua) that makes life
> (much) easier to packagers, period. When you are cross-compiling (and
> guess what I'm doing right now?) it is not usefull, it is essential!
> 
> Every distro I used (archlinux, debian, ubuntu and fedora) provides its
> own version of lua*.pc and they will never agree until something is
> proposed upstream. And this means, as Taylan correctly specified,
> generating and installing a text file.
> 

And every one of those distros is just Linux, and a mainstream Linux distro
at that. Now try to compile something (cross or not) with a _hard_
dependency on pkg-config on something other than Linux or a BSD with
pkg-config installed. I regularly build most of my Lua modules on not just
Linux and the BSDs, but also OS X (with _only_ the native toolchain),
Solaris, and AIX.

And it's not essential for cross-compiling, it simply makes it easier. The
autoconf macro PKG_PROG_PKG_CONFIG will look for ${CHOST}-pkg-config when
choosing which pkg-config utility to use. Awesome. But that still requires
pkg-config, and also that each dependency is plugged into pkg-config. Even
if I installed pkg-config on OS X, Solaris, and AIX, it wouldn't do any good
as I'm not using a mainstream package manager in those environments.

I never said pkg-config isn't useful. It's very useful. I said it sucks when
there's a hard dependency on it. And I think some people are relying on it
too heavily, such that they make it unnecessarily difficult to build their
code on non-mainstream environments, even non-mainstream Linux environments.

pkg-config also has it's own warts. It doesn't differentiate --cflags
from --cppflags. Maybe you want to build your software using a different
compiler, e.g. Sun Studio instead of GCC on Solaris, but --cflags might
contain a flag that doesn't work during compilation. There's --cflags-only-I,
but what about -D switches? 

And what about multi-arch support? Lacking.

Furthermore, there isn't just _one_ pkg-config. OpenBSD has their own
pkg-config utility. FreeBSD Ports and Alpine Linux use
https://github.com/pkgconf/pkgconf. Those versions aren't 100% compatible.
For example, the OpenBSD implementation doesn't support --print-variables.
pkgconf doesn't support --print-provides.

Lua in particular exposes some other poor assumptions that pkg-config makes.
It never attended to querying things like installation paths. Querying
$prefix doesn't cut it. You can't assume that, e.g., Lua modules are
installed at ${prefix}/lib/lua/$V. On Ubuntu, for example, they go in
${prefix}/lib/${arch}/lua/$V. Although you wouldn't know that if did
pkg-config --variable INSTALL_CMOD luajit on Ubuntu 14.04, which prints
"/usr//lib/lua/5.1".

At best pkg-config makes simple and moderately complex tasks more simple.
That's without a doubt useful. But relied on inappropriately--such as to the
detriment of being able to explicitly specify information--and it makes
difficult things (like real build portability) even more difficult.

I'm not for or against PUC Lua shipping with it's own .pc file. Although I
do think that because few if any package maintainers use the existing build
framework as-is, I would discount the effect it might bring in terms of
consistency.