[bug#39599,1/4] build-system: Add copy-build-system.

I had to revert your documentation changes to get Guix to compile. I think you are missing '@end defvr' somewhere. Also, I packaged PaperWM using copy-build-system as an additional test case. The patch is attached.

Good work, Pierre!

Great, I'll merge tomorrow then if no one objects!

Hello Pierre,

> Great, I'll merge tomorrow then if no one objects!

No strong objection, but I did a few remarks here[1].

Thanks,

Mathieu

[1]: https://lists.gnu.org/archive/html/guix-patches/2020-02/msg00500.html

Should we add a mention in guix pull's "news"?

Le 20 février 2020 10:41:06 GMT-05:00, Pierre Neidhardt <mail@ambrevar.xyz> a écrit :
>Should we add a mention in guix pull's "news"?

It feels like this is an internal change that doesn't really affect end-user experience.

Fair enough.

Alex,

On Thu, 20 Feb 2020, Alex Griffin wrote:

> I packaged PaperWM using copy-build-system as an additional test case.

This is great! I learned about PaperWM from your patch, and I've been having
lots of fun with it.

> +     '(#:install-plan
> +       '(("." "share/gnome-shell/extensions/paperwm@hedning:matrix.org"
> +          #:include-regexp ("\\.js(on)?$" "\\.css$" "\\.ui$" "\\.png$"
> +                            "\\.xml$" "\\.compiled$")))))

Seeing "compiled" here caught my attention. Since all we are doing so far is
copying files around, I expect everything to be in source form.

In this case the compiled file is a compiled glib schema. I've prepared a
second version of the patch that removes this file in a source snippet and
compiles it from the source in a new build phase.

This is another testament to the usefulness of the copy-build-system. It would
have been much more work to make the same modification to a package that uses
the trivial-build-system. Thanks Pierre!

Best,
Jack

Pushed!
Alex, I've included your patch.
Thanks to you all!

Hello,

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Pushed!

Thank you for this useful addition!

I added a few fixes to the Texinfo part of your patch.

Moreover, the indentation is very odd there, compared to the rest of
"guix.texi". You may want to normalize it.

Regards,

Hi Nicolas!

> I added a few fixes to the Texinfo part of your patch.

Thanks for those painful changes :D
>
> Moreover, the indentation is very odd there, compared to the rest of
> "guix.texi". You may want to normalize it.

Oh, yes, I see that.  I thought it would help with readability.  How are
we supposed to visualize nested @itemize at the moment?

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Oh, yes, I see that.  I thought it would help with readability.  How are
> we supposed to visualize nested @itemize at the moment?

I don't think there's a clear answer, but, IMO, for readability sake, we
should not (ab)use nested lists in a manual. 

There are three levels of such lists here. I think this is not
necessary. For example

--8<---------------cut here---------------start------------->8---
@item When @var{source} matches a file or directory without trailing slash, install it to @var{target}.
  @itemize
  @item If @var{target} has a trailing slash, install @var{source} basename beneath @var{target}.
  @item Otherwise install @var{source} as @var{target}.
  @end itemize
--8<---------------cut here---------------end--------------->8---

could be written as, e.g.,

--8<---------------cut here---------------start------------->8---
@item
When @var{source} matches a file or directory without a trailing slash,
install it to @var{target}.  More accurately, if @var{target} ends with
a slash, install @var{source} basename beneath @var{target} directory.
Otherwise install @var{source} as @var{target}.
--8<---------------cut here---------------end--------------->8---

Similarly, instead of discussing about #:include and al. in a nested
list, this could happen in a subsequent paragraph, once "source" and
"target" are clarified, i.e., after "In all cases, the paths (BTW,
shouldn't it be "file names"?) relative to @var{source} are preserved
within @var{target}."

As a side note, are you sure about: "With @code{#:include}, install all
the files which (I would use "whose" here, but I'm not a native speaker)
path suffix (isn't it "basename" or, possibly better, "base name"
instead?) exactly matches one of the elements in the given list"? Do you
really mean that a file name matching two regexps is _not_ going to be
included?

Note that I know writing documentation is tedious; I don't want to sound
negative or boring.

Regards,

Pierre,

Nicolas Goaziou 写道：
> Moreover, the indentation is very odd there, compared to the 
> rest of
> "guix.texi". You may want to normalize it.

More than just odd, unfortunately.  It broke ‘guix pull’ on 
master:
./guix.de.texi:6631: warning: @end should only appear at the 
beginning of a line
./guix.de.texi:6635: warning: @itemize should only appear at the 
beginning of a line
./guix.de.texi:6635: warning: @item should not appear in @itemize
./guix.de.texi:6635: @item outside of table or list
./guix.de.texi:6639: warning: @itemize should only appear at the 
beginning of a line
./guix.de.texi:6639: warning: @item should not appear in @itemize
./guix.de.texi:6639: @item outside of table or list
./guix.de.texi:6647: warning: @end should only appear at the 
beginning of a line
./guix.de.texi:6648: superfluous argument to @end itemize:  In all 
cases, the paths relative to @var{source} are>
Backtrace:
           3 (primitive-load 
           "/gnu/store/qsd0khinmy748z6aq23ck8lcaxr?")
In ice-9/eval.scm:
    619:8  2 (_ #f)
In ice-9/boot-9.scm:
   260:13  1 (for-each #<procedure 7ffff4f4f2a0 at 
   ice-9/eval.scm:3?> ?)
In guix/build/utils.scm:
    652:6  0 (invoke _ . _)

guix/build/utils.scm:652:6: In procedure invoke:
ERROR:
  1. &invoke-error:
      program: 
      "/gnu/store/irj21yhgls637jhhkb5yr79s76c96maq-texinfo-6.6/bin/makeinfo"
      arguments: ("./guix.de.texi" "-I" 
      "/gnu/store/ygairf8pckyzl1aplf0jxmbzr9gnhjik-doc" "-I" "." 
      "-o" "/gnu/st>
      exit-status: 1
      term-signal: #f
      stop-signal: #f
I removed *all* leading whitespace in 
af51d01a8aa8d7cf529173bdb64392f14eb21962 and this fixes the 
problem.  In future, avoid it altogether.  It clashes with the 
rest of the file even when it doesn't break anything.

If you're using some kind of fancy-texinfo-mode please disable it, 
although I wonder who writes a mode that breaks things so badly 
:-p

Kind regards,

T G-R

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Oh, yes, I see that.  I thought it would help with readability.  How are
>> we supposed to visualize nested @itemize at the moment?
>
> I don't think there's a clear answer, but, IMO, for readability sake, we
> should not (ab)use nested lists in a manual. 
>
> There are three levels of such lists here. I think this is not
> necessary. For example
>
> --8<---------------cut here---------------start------------->8---
> @item When @var{source} matches a file or directory without trailing slash, install it to @var{target}.
>   @itemize
>   @item If @var{target} has a trailing slash, install @var{source} basename beneath @var{target}.
>   @item Otherwise install @var{source} as @var{target}.
>   @end itemize
> --8<---------------cut here---------------end--------------->8---
>
> could be written as, e.g.,
>
> --8<---------------cut here---------------start------------->8---
> @item
> When @var{source} matches a file or directory without a trailing slash,
> install it to @var{target}.  More accurately, if @var{target} ends with
> a slash, install @var{source} basename beneath @var{target} directory.
> Otherwise install @var{source} as @var{target}.
> --8<---------------cut here---------------end--------------->8---

Fair enough.
The idea behind the items was to structure it like a spec that would
easily translate to code then.
(I wrote these specs before writing the code.)

> Similarly, instead of discussing about #:include and al. in a nested
> list, this could happen in a subsequent paragraph, once "source" and
> "target" are clarified, i.e., after "In all cases, the paths (BTW,
> shouldn't it be "file names"?)

I don't know.  In my opinion, "file names" is often interpreted as "base
names".  Here I mean that the full subpath of the file is preserved.
May I should use "subpath" then.

> As a side note, are you sure about: "With @code{#:include}, install all
> the files which (I would use "whose" here, but I'm not a native
> speaker)

https://en.wikipedia.org/wiki/Inanimate_whose

Actually, should be "which the" or "the files the path of which".
But all this is very pedantic :)

> path suffix (isn't it "basename" or, possibly better, "base name"
> instead?)

No, it really is "path suffix" here because it matches against the
parent directories, e.g. "foo/bar" is a valid suffix.

> exactly matches one of the elements in the given list"? Do you
> really mean that a file name matching two regexps is _not_ going to be
> included?

Indeed, that's a mistake!  Thanks!.

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> I removed *all* leading whitespace in 
> af51d01a8aa8d7cf529173bdb64392f14eb21962 and this fixes the 
> problem.  In future, avoid it altogether.  It clashes with the 
> rest of the file even when it doesn't break anything.

Thanks for the fix.

> If you're using some kind of fancy-texinfo-mode please disable it, 
> although I wonder who writes a mode that breaks things so badly 
> :-p

I don't, I just indented manually.  It was impossible to read otherwise.
Well, Texinfo is a bit tedious, I guess we have to leave with it.

Crazy that "guix pull" broke and not "make".  I wonder why "guix pull"
is so sensitive.