[bug#62551] Added new transformation option: --with-configure-flag

[Ludovic Courtès]

Hello!

Sarthak Shah <shahsarthakw@gmail.com> skribis:

> This patch adds a new transformation option that lets the user specify a
> package to add an extra #:configure-flags value to. Functionally, it is
> quite similar to the --with-patch transform.
> Currently, I've generated a list of build systems that do not support
> #:configure-flags that this transform checks against, but this could be
> improved by making the transform check if any given transform has the
> #:configure-flags keyword in its arguments.
> Please test this patch if possible; my preliminary testing indicates that
> it is working, however it could fail for edge cases I have not considered.
> CCing Ludovic as he might be interested in this.

Nice, that’s a great start!

> +  (define (package-with-configure-flag p extra-flag)
> +    (package/inherit p
> +      (arguments
> +       (substitute-keyword-arguments (package-arguments p)
> +         ((#:configure-flags list-of-flags (quote '()))
> +          ;; here extra-flag takes the form (--extra-flag)
> +          ;; hence it must be spliced to avoid eval errors
> +          `(cons* ,@extra-flag ,list-of-flags))))))

“Nowadays” we’d use gexps, like so:

  #~(cons* #$extra-flags #$list-of-flags)

> +  (define (coalesce-alist alist)
> +    ;; Coalesce multiple occurrences of the same key in ALIST.

This seems to be pasted from somewhere else; we might want to factorize
it (not your fault of course, but something to keep in mind.)

> +  (define %BUILD-SYSTEMS-WITHOUT-CONFIGURE-FLAGS
> +    ;; These build systems do not have a #:configure-flags parameter
> +'(android-ndk asdf/sbcl asdf/ecl asdf/source cargo channel chicken clojure

In general, the ‘name’ field of build systems is purely informational
and I would suggest not relying on it.

Actually, I would probably not perform any check at all.  After all, the
“contract” we have with users of transformation options is that it’s “at
their own risk”: these options build a new package that may or may not
“work”, broadly speaking.

Then we could think of a more sophisticated approach where build systems
would have a field listing supported flags or something along these
lines.  But again, I would not bother about it for now.

The rest looks great!

Have you been able to test it on actual packages? (I haven’t taken the
time yet.)

What we’d like to have, in addition to this, is two things:

  1. Unit tests in ‘tests/transformations.scm’, similar to those of
     other transformations.  Check out
     
<https://guix.gnu.org/manual/devel/en/html_node/Running-the-Test-Suite.html>
     on how to run the test suite.

  2. A few lines in ‘doc/guix.texi’ describing the new option, under
     “Package Transformation Options”.

Could you give it a try?

Anyways, kudos for this first step!

Ludo’.