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 <[email protected]> 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 > >
