zimoun <zimon.touto...@gmail.com> writes: Hi,
Thanks for your reply, I appreciate you taking time to respond to my silly message <3. > Hi, > > Thanks for your comments. > > On lun., 26 sept. 2022 at 10:39, Mája Tomášek <maya.toma...@disroot.org> > wrote: > >> (package >> ... >> (inputs list-of-inputs) >> (build-system some-build-system) >> (arguments (list-of-quoted #:key value)) >> ... >> ) > > [...] > >> (package >> ... >> (inputs list-of-inputs) >> (build-system >> (some-build-system >> (phases new-list-of-phases) >> (strip-binaries? #f))) >> ... >> ) > > Hum, from the surface, your proposal is to just move the arguments. > Currently, ’arguments’ are related to ’build-system’ – therefore, I do > not the difference between your proposal and the current situation. The main point was to define a more ergonomic and sanitized way to configure the build system. For example, there's currently no guarantee that #:phases will contain list of functions and the error from that will be cryptic. Contrast that with the service-configuration API. There are field sanitizers that ensure that the configuration is propper and easily one can introspect what the build system accepts and what are the defaults. > > However, this… > >> (define-build-system some-build-system >> (inherit gnu-build-system) >> (name 'some) >> (description "Some build system") >> (phases %standard-phases) >> (strip-binaries? #t) >> ... >> (builder (thunked) >> (build-system->builder this-build-system)) >> ) >> >> The build-system->builder method would generate the build, with >> arguments properly adjusted, records translated into keyword arguments, >> for a standard build system, the alternative, >> would be to provide a (lambda (build-system) >> some-code-that-returns-derivation). >> >> The current system is good, but when you need to write your own build >> system, you needlessly need to write thins like ungexping arguments, >> running gexp->derivation, which is really the system by which the guix >> daemon operates, but which could really be abstracted away from the >> build system developer. The code writing for a complete build system is >> repetetive >> and complicated. > > …is something different. Yeah, maybe some glue helpers could ease the > creation of new build-system. Nevertheless, please note that a > build-system somehow needs some plumbing and I am not convinced that > it would be doable to define a new build-system without diving in some > G-exp here or there. > > I agree that the composition of existing bricks is not always > straightforward and it could be improved, eventually. :-) I understand that some gexps are nescessary, and I really do love gexps :D. Yet my point was mostly on that as a build system developer, I need to concern myself with store-monad and derivations, even though I am more concerned with the package build steps. Best regards, Maya