[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/7] gnu: Add idris-lightyear.

From: Ludovic Courtès
Subject: Re: [PATCH 4/7] gnu: Add idris-lightyear.
Date: Tue, 03 Jan 2017 16:05:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

David Craven <address@hidden> skribis:

>> IMO you can push this patch as is and provide an ‘idris-build-system’
>> later on, or do the latter first.  Either way is fine with me as long as
>> we don’t wait until there are ten users of ‘idris-default-arguments’.
>> WDYT?
> Regarding that, I think it's harder than it should be to add new build
> systems at the moment. I think that adding a new build system requires
> a substantial amount of boiler plate.
> Would it make sense to have a phase-build-system that could be easily
> extended with custom phases and cherry pick from a collection of
> generic phases or something like that? Then we could simplify the
> gnu-build-system to include only gnu-build-system specific stuff?

Yeah, it’s too much boilerplate, though in this case I think it would be
quite reasonable

  (define (set-build-arguments b)
      (inherit b)
      (arguments '(#:modules … #:phases …))))

  (define idris-build-system
      (lower (compose set-build-arguments
                      (build-system-lower gnu-build-system)))))

and then you could have:

  (define-module (guix build idris-build-system)
    #:use-module ((guix build gnu-build-system) #:prefix gnu:))
    #:export (%standard-phases))

  (define %standard-phases
    (modify-phases gnu:%standard-phases …))

> This could also be a good time to reinvestigate using gexp's in the
> build systems. Would the problem that Danny had with imported modules
> compiled not finding libgcrypt be solved by using gexp's?

The ‘wip-build-systems-gexp’ branch is still around and I plan to look
into it again…

> I'm aware that this would be a substantial effort and maybe it's not
> currently that important. But there seems to be interest in also
> adding an ocaml-build-system, and the rust-build-system is a work in
> progress. Maybe we could ease the transition by having the new build
> systems use a phase-build-system as a base, without having to change
> existing build-systems and giving some more lead way in experimenting,
> since it wouldn't break any existing packages.

I’m not sure what a ‘phase-build-system’ would look like, if not like
‘gnu-build-system’, but it’s an interesting idea to explore.

Dave Thompson recently suggested that maybe phases could be first-class,
i.e., directly exposed on the “host side”, which is indeed a valid
design question.  Another thing worth exploring!


reply via email to

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