Hey Kristian, On Sun, 22 Sep 2024 22:50:43 +0200 Kristian Lein-Mathisen <[email protected]> wrote:
> That is well spotted, Mario! (foreign-dependencies ...) would always just > affect the current (csc-options ...), so > perhaps doesn't deserve its own property. > > I still think there is some level of usefulness in pkg-config: The hope is > that its package identifier names are > consistent across all systems. > If that is the case, I'd expect it to be a worthy optional build-time > dependency. I started looking into how > pkg-config package identifiers might differ but > did not complete any exhaustive search. I'll post updates here if I get > around to checking various pkg-config > identifiers against different OSes/distributions. > > I wonder if it wouldn't be too confusing to then just replace > (foreign-dependencies (pkg-config <pkg>)) > with, for example, > (csc-options "-O3" (pkg-config <pkg>)) My problem with pkg-config specifically is that it brings a sort of "vendor lock-in" problem to the egg specification format. I'm pretty sure at some point someone will come up with a better, faster and safer implementation of what pkg-config does (it can even be in CHICKEN, in case you were thinking of Rust :-)). The approach of having a custom-config form that references a program to be called at build time would give us more flexibility. That program can be in CHICKEN, and we could have a CHICKEN egg that provides a simple pkg-config procedure that can be called from a custom-config program. In that case, the custom-config program can be as simple as something like: (import pkg-config) (pkg-config the-package) The implementation of the `pkg-config' procedure would abstract all the magic to provide the right compiler/linker flags. It can be as simple as calling the system pkg-config program or even a Scheme implementation of pkg-config. The pkg-config egg can be specified as `build-dependencies' (already supported by the egg specification format), so that it it'll be available to be used from custom-config programs. So far we've been talking about pkg-config, and only in this scope we already have pkg-config, pkconf and u-conf (https://github.com/skeeto/u-config), as far as I know. Properly supporting pkg-config features as an egg tends to be easier than as a core module, specially when we take into account support for cross-compilation, multiple pkg-config implementations and multiple OS platforms. Also custom-config programs don't have to be limited to pkg-config. They can be used to handle any other weird cases without a tight coupling to the CHICKEN core. All the best. Mario -- http://parenteses.org/mario
