[Top][All Lists]

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

Re: [PATCH 1/2] build: Generalize 'package-with-explicit-python'.

From: Ludovic Courtès
Subject: Re: [PATCH 1/2] build: Generalize 'package-with-explicit-python'.
Date: Fri, 10 Feb 2017 17:18:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)


Federico Beffa <address@hidden> skribis:

> +(define* (package-with-explicit-compiler compiler bs-name
> +                                         old-prefix new-prefix
> +                                         #:key variant-property)
> +  "Return a procedure of one argument, P.  The procedure creates a package
> +with the same fields as P, which is assumed a build-system named BS-NAME, 
> such
> +that it is compiled with COMPILER instead.  The inputs are changed 
> recursively
> +accordingly.  If the name of P starts with OLD-PREFIX, this is replaced by
> +NEW-PREFIX; otherwise, NEW-PREFIX is prepended to the name.
> +
> +When VARIANT-PROPERTY is present, it is used as a key to search for
> +pre-defined variants of this transformation recorded in the 'properties' 
> field
> +of packages.  The property value must be the promise of a package.  This is a
> +convenient way for package writers to force the transformation to use
> +pre-defined variants."

Great idea, along with --with-compiler.

However, I think this:

> +  (define compiler-keyword
> +    (case bs-name
> +      ((haskell python emacs perl r ruby) (symbol->keyword bs-name))
> +      (else
> +       (leave (_ "Operation not supported by the build system: ~A~%") 
> bs-name))))

and this:

> +         ;; Otherwise build the new package object graph.
> +         ((eq? (build-system-name (package-build-system p)) bs-name)

are kind of hacks (the build system name is supposed to be used for
debugging purposes only, and not for identification) and not very
extensible (we’d have to extend the ‘case’ above for every new build

What we’re trying to achieve here is similar to
‘package-input-rewriting’ and --with-input, except that it should
additionally take into account implicit inputs.

For that reason I’d suggest a new ‘package-input-rewriting*’ that would:

  1. Call ‘package-input-rewriting’;

  2. Change the ‘build-system’ field of the result and inject a “proxy”
     build system in order to be able to change the inputs of the bag
     (which includes the package’s implicit inputs).

Then we could change --with-input to use this new procedure, and
--with-input=r=my-r would DTRT.



reply via email to

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