From: ludo@gnu.org (Ludovic Courtès)
To: David Craven <david@craven.ch>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: [PATCH 4/7] gnu: Add idris-lightyear.
Date: Tue, 03 Jan 2017 16:05:32 +0100 [thread overview]
Message-ID: <8737h0420z.fsf@gnu.org> (raw)
In-Reply-To: <CAL1_imkvVzzR0zrjn4B4YOqT=StTu_DPfWzFk6Hzd1Fx_3KZXw@mail.gmail.com> (David Craven's message of "Tue, 3 Jan 2017 14:13:18 +0100")
David Craven <david@craven.ch> 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)
(bag
(inherit b)
(arguments '(#:modules … #:phases …))))
(define idris-build-system
(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!
Ludo’.
next prev parent reply other threads:[~2017-01-03 15:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 17:19 [PATCH 1/7] git-download: Add some helpers David Craven
2017-01-02 17:19 ` [PATCH 2/7] gnu: Order module imports in (gnu packages haskell) alphabetically David Craven
2017-01-03 12:22 ` Ludovic Courtès
2017-01-02 17:19 ` [PATCH 3/7] gnu: idris: Update to 0.99 David Craven
2017-01-03 12:22 ` Ludovic Courtès
2017-01-03 12:29 ` Ludovic Courtès
2017-01-02 17:19 ` [PATCH 4/7] gnu: Add idris-lightyear David Craven
2017-01-03 12:26 ` Ludovic Courtès
2017-01-03 13:13 ` David Craven
2017-01-03 15:05 ` Ludovic Courtès [this message]
2017-01-03 15:08 ` David Craven
2017-01-03 18:21 ` David Craven
2017-01-05 10:43 ` Ludovic Courtès
2017-01-02 17:19 ` [PATCH 5/7] gnu: Add idris-wl-pprint David Craven
2017-01-03 12:28 ` Ludovic Courtès
2017-01-02 17:19 ` [PATCH 6/7] gnu: Add idris-bifunctors David Craven
2017-01-03 12:27 ` Ludovic Courtès
2017-01-02 17:19 ` [PATCH 7/7] gnu: Add idris-lens David Craven
2017-01-03 12:27 ` Ludovic Courtès
2017-01-03 12:28 ` [PATCH 1/7] git-download: Add some helpers Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8737h0420z.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=david@craven.ch \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).