Re: [Chicken-hackers] pkg-config support in chicken-install

[Lassi Kortela]

Thanks for chiming in Peter :)

> The thing is, pkg-config is quite Linux-centric, even if it's from the
> Freedesktop project.  It exists on other platforms (BSD, Mac) too, but
> it's usually an optional add-on.  On Windows it's probably not there.

It ships by default with OpenBSD and probably with lots of Linux 
distros. It's very easy to install on NetBSD, FreeBSD and DragonFlyBSD 
(one small package from the OS package manager).

No idea about Windows, I admit.

> So we certainly can't rely on it being there.

We'd have to do the equivalent of `which pkg-config` to find it. If we 
can't find it, we should tell the user how to install it (by hard-coding 
a lookup table of which OS package installs pkg-config on each OS - this 
is trivial, maybe 10 entries).

I'd advocate a policy of requiring pkg-config on Unix-like operating 
systems for eggs that use C libraries. pkg-config is so simple, easily 
obtainable and solves the problem so well that people who refuse to use 
it are basically asking for difficulties (not only with Chicken, but 
probably with most other languages eventually).

For users who want custom compiler flags or library versions, it's easy 
to write a small .pc file and put it in PKG_CONFIG_PATH.

Again, not sure how things are on Windows. Do people usually install 
Chicken from Chocolatey nowadays, or how does it go?

> However, not using pkg-config means you end up with a pile of
> autoconf-like guessing steps, where you try out some test compilation
> with "educated guesses" of what you might conceivably need to pass to
> the compiler to make it work.

Exactly :) And the solution would be Chicken-only and would probably go 
out of date at some point (it's not rare for configure scripts to break).

> It might be nice if we can have a set of default things to try on each
> platform, which could include calling pkg-config.  Bonus points if it's
> configurable by the user.

Interested in hearing if you have alternatives besides pkg-config. I'm 
not aware of any but I haven't looked hard.

The big selling point of pkg-config is that it does the very thing we 
would do anyway (specify compiler and linker flags) but in a 
standardized way, so we can leverage the work of other language 
communities and OS packagers have already put in. If some C library 
doesn't come with pkg-config definitions, they are easy to write, and we 
can use the standard status of pkg-config to encourage upstream 
packagers to add definitions to the next version of the upstream package.

> OTOH, it shouldn't be over-engineered and this kind of thing will quickly
> reach for the stars.

Agreed.