[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Lassi Kortela
Subject: Re: [Chicken-hackers] pkg-config support in chicken-install
Date: Thu, 18 Jul 2019 17:05:39 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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 :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]