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

[Lassi Kortela]

Thanks for the very fast reply! You have a super approachable community :)

> Personally, I'm not overly keen on builtin support for any configuration
> mechanism. Where will it end? What about Windows? What about other
> tools that do similar things as pkg-config? Once we start this, there will be
> no end to it (and I exaggerate only slightly...)

I respect your point of view, and agree that a snowball effect of 
supporting more and more idiosyncratic things in the core is not good.

I would make an exception for pkg-config because it is:

1) almost ubiquitous
2) extremely simple
3) quite uncontroversial (essentially .ini files listing the same flags 
we'd be passing to compilers anyway, but in a standard format)

If all of these weren't true, I would probably be wary of the idea too.

> chicken-install is not a package manager. I understand that without
> a solid configuration system it is very difficult to support smooth builds
> in a language/library implementation that attempts to be portable across
> a wide range of operating systems. But CHICKEN is first anf foremost a Scheme
> implementation with the facility of basic library-management.
> Installing Scheme-only libraries is usually effortless and that is enough,
> in my very very humble opinion. In situations where it would be useful
> to support quasi-generic, yet still OS-dependent components, I suggest
> to do the configuration in Scheme as much as possible and assume
> reasonable defaults, depending on platform.

The thing is, the reasonable defaults usually involve installing 
software from the OS package manager in addition to the Chicken egg, so 
it'd be very useful if the egg description lists the names of the 
requisite OS packages.

Once the OS packages are installed, the reasonable defaults for compiler 
and linker flags are the exact job for which pkg-config was built.

There are other things that an egg's build script can detect (feel free 
to point at complex examples :) but people who work on that stuff 
basically enter a world of pain - arcane, buggy, non-portable stuff that 
can and often does change between OS and package releases.

So from an egg's point of view, a reasonable policy might be "These are 
the pkg-config pacakge names, and these are the OS packages from which 
you can install them. If you need something more complex, you need to 
set things up yourself so that the pkg-config package names work as 
expected." Again, glad to hear any counterexamples of why this wouldn't 
work.

> Yes, this is hard and not
> without rough edge cases and even installation woes, I fully admit
> that, but I see no acceptable solution that is generic, portable and
> maintainable enough to be worth putting effiort into.

I approached this from the point of view of "how much convenience and 
reliability can we buy for how many lines of code". pkg-config support 
is tricky (which is why I suggest centralizing it in chicken-install) 
but it's not _that_ tricky.

If there's still interest, I can try to write a prototype in Scheme. 
Then there's something concrete to talk about. But if you are completely 
opposed to doing things like this already, I respect your wishes - after 
all it's your implementation and I'm an outsider. No hard feelings :)