LAPACK: tests fail; non-free files

LAPACK: tests fail; non-free files

[Nikita Karetnikov]

[-- Attachment #1.1: Type: text/plain, Size: 861 bytes --]

The attached patch requires this one [1].

1. Could anyone explain why the tests fail?

   100% tests passed, 0 tests failed out of 86

   Total Test time (real) = 169.48 sec
   No such file or directory
   Problem running command: ./lapack_testing.py -s -d TESTING
   Problem executing post-test command(s).
   Errors while running CTest
   make: *** [test] Error 8
   phase `check' failed after 169 seconds

   When I sourced environment-variables and ran ‘lapack_testing.py’, it
   didn’t complain.  So it must be something else.  How can I pass the
   verbose flag to CMake?

2. These files are not free:

   lapacke/example/example_DGESV_rowmajor.c
   lapacke/example/example_ZGESV_rowmajor.c

   Should I report upstream or simply remove them?

[1] https://lists.gnu.org/archive/html/guix-devel/2013-10/txtEV9ZKOlmFQ.txt


[-- Attachment #1.2: lapack.scm --]
[-- Type: text/plain, Size: 2470 bytes --]

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(define-module (gnu packages lapack)
  #:use-module (guix licenses)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system cmake)
  #:use-module (gnu packages gcc)
  #:use-module (gnu packages python))

(define-public lapack
  (package
    (name "lapack")
    (version "3.4.2")
    (source
     (origin
      (method url-fetch)
      (uri (string-append "http://www.netlib.org/lapack/lapack-"
                          version ".tgz"))
      (sha256
       (base32
        "1w7sf8888m7fi2kyx1fzgbm22193l8c2d53m8q1ibhvfy6m5v9k0"))))
    (build-system cmake-build-system)
    (home-page "http://www.gnu.org/software/lapack/")
    (inputs `(("fortran" ,gcc-fortran-4.8)
              ("python" ,python-2)))
    (arguments `(#:modules ((guix build cmake-build-system)
                            (guix build utils)
                            (srfi srfi-1))
                 #:phases (alist-cons-before
                           'check 'patch-python
                           (lambda* (#:key inputs #:allow-other-keys)
                             (let ((python (assoc-ref inputs "python")))
                               (substitute* "lapack_testing.py"
                                 (("/usr/bin/env python") python))))
                           %standard-phases)))
    (synopsis "Library for numerical linear algebra")
    (description
     "LAPACK is a Fortran 90 library for solving the most commonly occurring
problems in numerical linear algebra.")
    (license (bsd-style "file://LICENSE"
                        "See LICENSE in the distribution."))))

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: LAPACK: tests fail; non-free files

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 79 bytes --]

> (home-page "http://www.gnu.org/software/lapack/")

Oops, I’ll fix this.

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: LAPACK: tests fail; non-free files

[Andreas Enge]

Hello Nikita,

On Wed, Oct 23, 2013 at 01:08:55PM +0400, Nikita Karetnikov wrote:
> The attached patch requires this one [1].

I would suggest to add lapack only after the fortran compiler is in master.
You might wish to put the variable into maths.scm.

> 2. These files are not free:
>    lapacke/example/example_DGESV_rowmajor.c
>    lapacke/example/example_ZGESV_rowmajor.c
>    Should I report upstream or simply remove them?

Debian removes them:
   http://ftp-master.metadata.debian.org/changelogs/main/l/lapack/unstable_copyright
So does Fedora:
   https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130325/987558.html
I would suggest to do the same; if you feel reporting it, it would be interes-
ting to see how upstream reacts.

Andreas

[PATCH] gnu: cmake: Bump to 2.8.12

[Cyril Roelandt]

* gnu/packages/cmake.scm: bump to 2.8.12
---
 gnu/packages/cmake.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


Our Nix friends seem to think that this is a cmake issue, likely to be fixed in
2.8.12:

http://www.mail-archive.com/nix-dev@lists.science.uu.nl/msg10114.html

Could you apply this patch and try to build lapack ? If this works, I'll push
it after making sure it does not break Qt (which implies fixing pulseaudio...)


Cyril.

diff --git a/gnu/packages/cmake.scm b/gnu/packages/cmake.scm
index a5c3d45..84873f4 100644
--- a/gnu/packages/cmake.scm
+++ b/gnu/packages/cmake.scm
@@ -27,7 +27,7 @@
 (define-public cmake
   (package
     (name "cmake")
-    (version "2.8.10.2")
+    (version "2.8.12")
     (source (origin
              (method url-fetch)
              (uri (string-append
@@ -36,7 +36,7 @@
                     (string-index version #\. (+ 1 (string-index version #\.))))
                    "/cmake-" version ".tar.gz"))
              (sha256
-              (base32 "1c8fj6i2x9sb39wc9av2ighj415mw33cxfrlfpafcvm0knrlylnf"))
+              (base32 "11q21vyrr6c6smyjy81k2k07zmn96ggjia9im9cxwvj0n88bm1fq"))
              (patches (list (search-patch "cmake-fix-tests.patch")))))
     (build-system gnu-build-system)
     (arguments
-- 
1.8.4.rc3

Re: LAPACK: tests fail; non-free files

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

> I would suggest to add lapack only after the fortran compiler is in
> master.

Sure.  But I won’t push the compiler without talking to Ludo.

> You might wish to put the variable into maths.scm.

OK.

> Debian removes them:
>    http://ftp-master.metadata.debian.org/changelogs/main/l/lapack/unstable_copyright
> So does Fedora:
>    https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130325/987558.html
> I would suggest to do the same; if you feel reporting it, it would be interes-
> ting to see how upstream reacts.

It was already reported [1].  I’ll remove all non-free files.

[1] http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01383.html

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] gnu: cmake: Bump to 2.8.12

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 213 bytes --]

> Could you apply this patch and try to build lapack ?

Thanks, it works.

@ build-succeeded /nix/store/wyzcbhijr8ibk2rn3rxiiyq2hbrfrwqr-lapack-3.4.2.drv -
/nix/store/gfzgj7ycqc1j8y094mma77ck4zbzvkf3-lapack-3.4.2

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] gnu: cmake: Bump to 2.8.12

[Ludovic Courtès]

Cyril Roelandt <tipecaml@gmail.com> skribis:

> Could you apply this patch and try to build lapack ? If this works, I'll push
> it after making sure it does not break Qt

Qt doesn’t depend on CMake AFAICS.  Am I missing something?

> (which implies fixing pulseaudio...)

So it had two test failures (‘volume-test’ and ‘thread-test’) on
hydra.gnu.org (which runs 2.6.32-xen), and none on my laptop (which runs
3.0.43).

I restarted the build a couple of times on hydra and it eventually
succeeded...

Not satisfying, but to me that suggests a timing issue.

Can someone reproduce these test failures?

Ludo’.

Re: [PATCH] gnu: cmake: Bump to 2.8.12

[Andreas Enge]

On Tue, Oct 29, 2013 at 12:14:21AM +0100, Ludovic Courtès wrote:
> Qt doesn’t depend on CMake AFAICS.  Am I missing something?

No, but kde does, which is the main "consumer" of qt. Probably I was
confusing things.

> So it had two test failures (‘volume-test’ and ‘thread-test’) on
> hydra.gnu.org (which runs 2.6.32-xen), and none on my laptop (which runs
> 3.0.43).
> I restarted the build a couple of times on hydra and it eventually
> succeeded...
> Not satisfying, but to me that suggests a timing issue.

If it happens again, maybe we should disable parallel tests?

Andreas

Re: [PATCH] gnu: cmake: Bump to 2.8.12

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, Oct 29, 2013 at 12:14:21AM +0100, Ludovic Courtès wrote:
>> Qt doesn’t depend on CMake AFAICS.  Am I missing something?
>
> No, but kde does, which is the main "consumer" of qt. Probably I was
> confusing things.

Ah, OK.

>> So it had two test failures (‘volume-test’ and ‘thread-test’) on
>> hydra.gnu.org (which runs 2.6.32-xen), and none on my laptop (which runs
>> 3.0.43).
>> I restarted the build a couple of times on hydra and it eventually
>> succeeded...
>> Not satisfying, but to me that suggests a timing issue.
>
> If it happens again, maybe we should disable parallel tests?

AFAICS the PulseAudio 4.0 tarball was generated with Automake 1.11,
where the ‘parallel-tests’ driver was disabled by default.  So tests are
run sequentially already.

We’d need to report it upstream, but I don’t really have enough info.
So it’d be great if someone could reproduce it and try to gather more
details.

Thanks,
Ludo’.

Re: [PATCH] gnu: cmake: Bump to 2.8.12

[Cyril Roelandt]

On 10/29/2013 12:14 AM, Ludovic Courtès wrote:
> I restarted the build a couple of times on hydra and it eventually
> succeeded...

I don't think I can build PA on my laptop though. Which means I can't 
build Qt, which means I can't push the cmake update, which means Nikita 
can't get Lapack working. What should we do ?


Cyril.

Re: [PATCH] gnu: cmake: Bump to 2.8.12

[Andreas Enge]

On Thu, Oct 31, 2013 at 11:42:57PM +0100, Cyril Roelandt wrote:
> I don't think I can build PA on my laptop though. Which means I
> can't build Qt, which means I can't push the cmake update, which
> means Nikita can't get Lapack working. What should we do ?

Please push the cmake update; I think I was mixing things up, qt does not
use cmake, but the gnu build system.

Andreas

[PATCH] gnu: Add LAPACK. (was: LAPACK: tests fail; non-free files)

[Nikita Karetnikov]

[-- Attachment #1.1: Type: text/plain, Size: 99 bytes --]

May I push this patch to ‘master’?  Should (format #t "removing '~a'~%"
file) be i18n’d?


[-- Attachment #1.2: 0001-gnu-Add-LAPACK.patch --]
[-- Type: text/x-diff, Size: 3669 bytes --]

From 3e94fe1afc01d08997fd95775aab06c4495ba9d6 Mon Sep 17 00:00:00 2001
From: Nikita Karetnikov <nikita@karetnikov.org>
Date: Mon, 4 Nov 2013 18:58:54 +0000
Subject: [PATCH] gnu: Add LAPACK.

* gnu/packages/maths.scm (lapack): New variable.
---
 gnu/packages/maths.scm |   49 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index ccbb57b..27d83f0 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013 Andreas Enge <andreas@enge.fr>
+;;; Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -22,13 +23,16 @@
                 #:renamer (symbol-prefix-proc 'license:))
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
   #:use-module (gnu packages compression)
   #:use-module ((gnu packages gettext)
                 #:renamer (symbol-prefix-proc 'gnu:))
+  #:use-module (gnu packages gcc)
   #:use-module (gnu packages multiprecision)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages python)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages xml))
 
@@ -153,3 +157,48 @@ interoperate with Gnumeric, LibreOffice and OpenOffice.  Data can be imported
 from spreadsheets, text files and database sources and it can be output in
 text, Postscript, PDF or HTML.")
     (license license:gpl3+)))
+
+(define-public lapack
+  (package
+    (name "lapack")
+    (version "3.4.2")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (string-append "http://www.netlib.org/lapack/lapack-"
+                          version ".tgz"))
+      (sha256
+       (base32
+        "1w7sf8888m7fi2kyx1fzgbm22193l8c2d53m8q1ibhvfy6m5v9k0"))))
+    (build-system cmake-build-system)
+    (home-page "http://www.netlib.org/lapack/")
+    (inputs `(("fortran" ,gfortran-4.8)
+              ("python" ,python-2)))
+    (arguments
+     `(#:modules ((guix build cmake-build-system)
+                  (guix build utils)
+                  (srfi srfi-1))
+       #:phases (alist-cons-before
+                 ;; See <http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01383.html>.
+                 'configure 'remove-non-free-files
+                 (lambda _
+                   (for-each (lambda (file)
+                               (begin
+                                 (format #t "removing '~a'~%" file)
+                                 (delete-file file)))
+                             '("lapacke/example/example_DGESV_rowmajor.c"
+                               "lapacke/example/example_ZGESV_rowmajor.c"
+                               "DOCS/psfig.tex")))
+                 (alist-cons-before
+                  'check 'patch-python
+                  (lambda* (#:key inputs #:allow-other-keys)
+                    (let ((python (assoc-ref inputs "python")))
+                      (substitute* "lapack_testing.py"
+                        (("/usr/bin/env python") python))))
+                  %standard-phases))))
+    (synopsis "Library for numerical linear algebra")
+    (description
+     "LAPACK is a Fortran 90 library for solving the most commonly occurring
+problems in numerical linear algebra.")
+    (license (license:bsd-style "file://LICENSE"
+                                "See LICENSE in the distribution."))))
-- 
1.7.9.5


[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] gnu: Add LAPACK.

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

> May I push this patch to ‘master’?

Yep!

> Should (format #t "removing '~a'~%"
> file) be i18n’d?

Definitely not: it’s essentially a debugging statement, and it’s only
visible in the build log.

+                 ;; See <http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01383.html>.
+                 'configure 'remove-non-free-files

It’s a case where ‘guix build -S’ will return the source including the
non-free files, which is clearly not what we want (though I gather that
the next upstream version of LAPACK will be fixed, right?).

Two things we could do: (1) add a ‘snippet’ field in ‘origin’, which is
where the ‘remove-file’ calls would appear, (2) host a freed version
under alpha.gnu.org/gnu/guix/mirror.

Hmm I’ll see if (1) can be implemented before 0.5 without triggering a
full rebuild.

Thanks,
Ludo’.

Re: [PATCH] gnu: Add LAPACK.

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

>> May I push this patch to ‘master’?

> Yep!

Done.

> (though I gather that the next upstream version of LAPACK will be
> fixed, right?).

I think so.

> Two things we could do: (1) add a ‘snippet’ field in ‘origin’, which is
> where the ‘remove-file’ calls would appear, (2) host a freed version
> under alpha.gnu.org/gnu/guix/mirror.

> Hmm I’ll see if (1) can be implemented before 0.5 without triggering a
> full rebuild.

OK, let me know if you need any help.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

‘snippet’ in <origin>

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> +                 ;; See <http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01383.html>.
> +                 'configure 'remove-non-free-files
>
> It’s a case where ‘guix build -S’ will return the source including the
> non-free files, which is clearly not what we want (though I gather that
> the next upstream version of LAPACK will be fixed, right?).
>
> Two things we could do: (1) add a ‘snippet’ field in ‘origin’, which is
> where the ‘remove-file’ calls would appear, (2) host a freed version
> under alpha.gnu.org/gnu/guix/mirror.

Commit f9cc897 in master adds a ‘snippet’ field in <origin>, which in
this particular case is used like this (commit 6a99575):

     (origin
      (method url-fetch)
      (uri (string-append "http://www.netlib.org/lapack/lapack-"
                          version ".tgz"))
      (sha256
       (base32
        "1w7sf8888m7fi2kyx1fzgbm22193l8c2d53m8q1ibhvfy6m5v9k0"))
      (snippet
       ;; Remove non-free files.
       ;; See <http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01383.html>.
       '(for-each (lambda (file)
                    (format #t "removing '~a'~%" file)
                    (delete-file file))
                  '("lapacke/example/example_DGESV_rowmajor.c"
                    "lapacke/example/example_ZGESV_rowmajor.c"
                    "DOCS/psfig.tex"))))

Problem solved.  :-)

This change breaks the ABI; make sure to run ‘make clean-go && make’!

Note that things occur in this order:

  1. The upstream source is unpacked.

  2. We chdir to the first directory created by that step (normally
     there is exactly one.)

  3. Patches are applied.

  4. The snippet is run.

  5. The directory is repacked.

Of course we get less flexibility by having things hardcoded this way,
but the goal is to keep it much simpler than what is done for <package>.

Mark: how well would this scheme apply to the mit-krb5 case?

Comments welcome!

Ludo’.

Re: ‘snippet’ in <origin>

[Mark H Weaver]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> +                 ;; See <http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01383.html>.
>> +                 'configure 'remove-non-free-files
>>
>> It’s a case where ‘guix build -S’ will return the source including the
>> non-free files, which is clearly not what we want (though I gather that
>> the next upstream version of LAPACK will be fixed, right?).
>>
>> Two things we could do: (1) add a ‘snippet’ field in ‘origin’, which is
>> where the ‘remove-file’ calls would appear, (2) host a freed version
>> under alpha.gnu.org/gnu/guix/mirror.
>
> Commit f9cc897 in master adds a ‘snippet’ field in <origin>, which in
> this particular case is used like this (commit 6a99575):

I think 'snippet' is a bad name for this field.  We may want to add
additional snippets in the future, such as an unpacking snippet.
Therefore, I think the field name should be based on what phase of the
process is being inserted or overridden.

> Note that things occur in this order:
>
>   1. The upstream source is unpacked.
>
>   2. We chdir to the first directory created by that step (normally
>      there is exactly one.)
>
>   3. Patches are applied.
>
>   4. The snippet is run.
>
>   5. The directory is repacked.
>
> Of course we get less flexibility by having things hardcoded this way,
> but the goal is to keep it much simpler than what is done for <package>.
>
> Mark: how well would this scheme apply to the mit-krb5 case?

I think it wouldn't work at all.  The upstream tarball does not contain
any directories, so step 2 would fail.  The tarball contains only two
top-level files: the compressed tarball with the actual source, and the
detached signature.

More generally, I'm not fond of this inflexible hardcoded approach.  I'd
prefer to have a set of phases (e.g. unpack, patch, delete, repack) that
can be selectively overridden if needed, but with some specialized
constructors that make things simple in the common cases.

What do you think?

      Mark

Re: ‘snippet’ in <origin>

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> ludo@gnu.org (Ludovic Courtès) skribis:
>>
>>> +                 ;; See <http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01383.html>.
>>> +                 'configure 'remove-non-free-files
>>>
>>> It’s a case where ‘guix build -S’ will return the source including the
>>> non-free files, which is clearly not what we want (though I gather that
>>> the next upstream version of LAPACK will be fixed, right?).
>>>
>>> Two things we could do: (1) add a ‘snippet’ field in ‘origin’, which is
>>> where the ‘remove-file’ calls would appear, (2) host a freed version
>>> under alpha.gnu.org/gnu/guix/mirror.
>>
>> Commit f9cc897 in master adds a ‘snippet’ field in <origin>, which in
>> this particular case is used like this (commit 6a99575):
>
> I think 'snippet' is a bad name for this field.  We may want to add
> additional snippets in the future, such as an unpacking snippet.
> Therefore, I think the field name should be based on what phase of the
> process is being inserted or overridden.

Hmm OK, makes sense.

>> Note that things occur in this order:
>>
>>   1. The upstream source is unpacked.
>>
>>   2. We chdir to the first directory created by that step (normally
>>      there is exactly one.)
>>
>>   3. Patches are applied.
>>
>>   4. The snippet is run.
>>
>>   5. The directory is repacked.
>>
>> Of course we get less flexibility by having things hardcoded this way,
>> but the goal is to keep it much simpler than what is done for <package>.
>>
>> Mark: how well would this scheme apply to the mit-krb5 case?
>
> I think it wouldn't work at all.  The upstream tarball does not contain
> any directories, so step 2 would fail.  The tarball contains only two
> top-level files: the compressed tarball with the actual source, and the
> detached signature.

OK.

> More generally, I'm not fond of this inflexible hardcoded approach.  I'd
> prefer to have a set of phases (e.g. unpack, patch, delete, repack) that
> can be selectively overridden if needed, but with some specialized
> constructors that make things simple in the common cases.
>
> What do you think?

The rationale for me is that <origin> should remain simple, while the
package’s build system would handle anything non-trivial.  For that
reason, and also because I knew it would avoid a full rebuild, I avoided
full-blown phases.

Now, I think we could replace ‘snippet’ by ‘phases’.  That field would
contain an <origin-phases> object with exactly 4 fields: unpack, patch,
user (default to #f), and repack.

In the LAPACK case, we’d do:

  (origin
    (uri ...)
    (sha256 ...)
    (phases (origin-phases (inherit %standard-origin-phases)
              (user '(for-each delete-file ...)))))

I think that would address your problem.  The set of phases would be
fixed, though, unlike what ‘gnu-build-system’ does, but I think that’s
fine.

How does that sound?

If that’s workable without triggering a full rebuild, I can look at it
by 0.5.  Otherwise that’ll have to wait.

Thanks for your feedback,
Ludo’.

Re: ‘snippet’ in <origin>

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> More generally, I'm not fond of this inflexible hardcoded approach.  I'd
>> prefer to have a set of phases (e.g. unpack, patch, delete, repack) that
>> can be selectively overridden if needed, but with some specialized
>> constructors that make things simple in the common cases.
>>
>> What do you think?
>
> The rationale for me is that <origin> should remain simple, while the
> package’s build system would handle anything non-trivial.  For that
> reason, and also because I knew it would avoid a full rebuild, I avoided
> full-blown phases.
>
> Now, I think we could replace ‘snippet’ by ‘phases’.  That field would
> contain an <origin-phases> object with exactly 4 fields: unpack, patch,
> user (default to #f), and repack.
>
> In the LAPACK case, we’d do:
>
>   (origin
>     (uri ...)
>     (sha256 ...)
>     (phases (origin-phases (inherit %standard-origin-phases)
>               (user '(for-each delete-file ...)))))
>
> I think that would address your problem.  The set of phases would be
> fixed, though, unlike what ‘gnu-build-system’ does, but I think that’s
> fine.
>
> How does that sound?

Sounds good to me!

> If that’s workable without triggering a full rebuild, I can look at it
> by 0.5.  Otherwise that’ll have to wait.

Indeed, let's not trigger a full rebuild :)

    Thanks,
      Mark

Re: ‘snippet’ in <origin>

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Now, I think we could replace ‘snippet’ by ‘phases’.  That field would
> contain an <origin-phases> object with exactly 4 fields: unpack, patch,
> user (default to #f), and repack.
>
> In the LAPACK case, we’d do:
>
>   (origin
>     (uri ...)
>     (sha256 ...)
>     (phases (origin-phases (inherit %standard-origin-phases)
>               (user '(for-each delete-file ...)))))
>
> I think that would address your problem.  The set of phases would be
> fixed, though, unlike what ‘gnu-build-system’ does, but I think that’s
> fine.

The problem with that is that it makes the semantics less obvious: the
‘phases’ field is only used when it has a ‘user’ value other than #f, or
when the origin has a ‘patches’ field.

It seems that it needs more thought.

Ludo’.