chicken-hackers
[Top][All Lists]
Advanced

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

Re: Proposal: using pkg-config for foreign dependencies in .egg-files


From: Mario Domenech Goulart
Subject: Re: Proposal: using pkg-config for foreign dependencies in .egg-files
Date: Tue, 24 Sep 2024 19:26:05 +0200

Hey Kristian,

On Sun, 22 Sep 2024 22:50:43 +0200 Kristian Lein-Mathisen 
<kristianlein@gmail.com> 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



reply via email to

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