From: ludo@gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <rekado@elephly.net>
Cc: help-guix <help-guix@gnu.org>, Federico Beffa <beffa@ieee.org>
Subject: Generalizing DAG rewriting
Date: Thu, 09 Feb 2017 10:55:06 +0100 [thread overview]
Message-ID: <87mvdv3czp.fsf_-_@gnu.org> (raw)
In-Reply-To: <874m04ekp4.fsf@elephly.net> (Ricardo Wurmus's message of "Wed, 08 Feb 2017 17:01:16 +0100")
Hi!
Ricardo Wurmus <rekado@elephly.net> skribis:
> Myles English <mylesenglish@gmail.com> writes:
>
>> Hello Fede, Eric,
>>
>> on [2017-02-07] at 15:15 Federico Beffa writes:
[...]
>>> it seems that the only Python specific part of
>>> 'package-with-explicit-python' is the keyword '#:python'. What do you
>>> think of generalizing it by making it a function keyword argument and
>>> move the procedure to its own module (maybe (guix build-system
>>> utils)?).
>>
>> ...I came the same conclusion as Fede: it could be generalised. It is
>> probably close to working for me (with respect to ghc) so I will keep
>> going for now. I am not competent enough to generalise it but if
>> someone else does I can help test it.
>
> I’m doing the same for some Perl packages. I defined a procedure
> “package-for-perl-5.14” which takes a package and rewrites it.
>
> It looks like this:
>
> (define (package-for-perl-5.14 pkg)
> (let* ((rewriter (package-input-rewriting `((,perl . ,perl-5.14))
> perl-5.14-package-name))
> (new (rewriter pkg)))
> (package
> (inherit new)
> (arguments `(#:perl ,perl-5.14
> ,@(package-arguments new))))))
>
> The problem here is that it doesn’t rewrite the “#:perl” argument
> recursively, so the dependencies of a Perl package will still refer to
> the latest version of Perl as that’s what’s used in the build system.
>
> We would need a solution that would take care of this problem for all
> build systems.
I agree that this is asking for generalization.
Another instance of DAG rewriting is the ‘package-with-’ helpers in
(guix build-system gnu).
We should have a general form of transformation procedure that handles
DAG traversal and memoization like all these procedures do.
Ludo’.
next prev parent reply other threads:[~2017-02-09 9:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 15:15 Recursively propagate build-system 'arguments' to dependency packages? Federico Beffa
2017-02-07 19:07 ` Myles English
2017-02-08 16:01 ` Ricardo Wurmus
2017-02-09 9:55 ` Ludovic Courtès [this message]
2017-02-09 23:47 ` Generalizing DAG rewriting Amirouche
2017-02-10 9:55 ` 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=87mvdv3czp.fsf_-_@gnu.org \
--to=ludo@gnu.org \
--cc=beffa@ieee.org \
--cc=help-guix@gnu.org \
--cc=rekado@elephly.net \
/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.
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).