On Wed, 18 Sep 2024 19:02:44 +0200 felix.winkelm...@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?
As long as we have an API between the egg specification and the custom-config program, we can use any executable, really. If we create eggs to abstract things like pkg-config, the more natural way to implement custom-config programs would be using CHICKEN code + eggs, indeed. > 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). All the best. Mario -- http://parenteses.org/mario
