[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