unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
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’.

  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).