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: Kristian Lein-Mathisen
Subject: Re: Proposal: using pkg-config for foreign dependencies in .egg-files
Date: Sun, 22 Sep 2024 22:50:43 +0200


Hi,

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

K.

On Wed, Sep 18, 2024 at 7:02 PM <felix.winkelmann@bevuta.com> wrote:

>
> How about having something like `custom-config', which can be mapped
> to a program that produces a list that can be read into the egg
> specification tree?
>
> Reusing your example:
>
> ```
> ((synopsis "ZStandard bindings")
>  (author "Kristian Lein-Mathisen")
>  (category data)
>  (license "BSD")
>  (dependencies)
>  (test-dependencies test)
>  (components
>    (extension zstd-loq-level
>               (source "zstd-module.scm")
>               (source-dependencies "zstd.scm")
>               (csc-options
>                 (custom-config "custom-config.scm"))) ;; <- custom config program
>              (extension zstd-nicer-api
>              (source "zstd-nicer-api.scm"))
>              (program "zcompress")))
> ```
>
> `custom-config.scm' would be a program that writes a list of options
> that would be used as `csc-options`.
>
> With that, we are more flexible and future-proof regarding the needs
> to adapt to different configuration mechanisms.  That also keeps the
> core free of dependencies and assumptions about external configuration
> tools.

I like this. So the custom config code would be a Scheme script, right?
We might want to support this regardless of how we proceed with
pkg-config. What I like about the pkg-config thing is that we have a
canonical way of specifying third-party packages, but on the other
hand every pseudo "standard" gets replaced at some stage by something
else.

The lack of declarativity is unfortunate, but we already have the ultime
loophole with custom-build (which includes the functionality of
custom-config but is of course more involved).


felix


reply via email to

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