Deprecating legacy build phase style when cross-compiling vs. native

Deprecating legacy build phase style when cross-compiling vs. native

[Josselin Poiret]

Hello everyone,

Following a report on IRC [1] that nss-certs wouldn't cross-build, I
found out that the old syntax of using %output instead of the shinier
$output was still supported only when native-compiling, and not when
cross-compiling, at least for build-systems inheriting from gnu.

Looking at guix/build-system/gnu.scm [2], we have gnu-build
vs. gnu-cross-build, which are responsible for native vs. cross-builds.
The former uses with-build-variables to set the legacy build variables
such as %output and %outputs (see the def in guix/gexp.scm), whereas the
latter does not, only doing so manually and so omitting %output.

This means that packages that were not updated to fit the new style
should all fail to cross-compile.  This simple bug could be resolved by
adding %output to gnu-cross-build, however as was argued on IRC this is
now undocumented behaviour and we'd rather switch all packages to the
new style instead.  While I 100% agree with this, I think we should have
a uniform deprecation policy for this matter, and that there shouldn't
be such a disparity between cross and native builds.

What do you all think?

[1] https://logs.guix.gnu.org/guix/2022-03-30.log#150521
[2] https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/gnu.scm?id=1c2da6603565bafba58b81742ce705dc8becb2f7

Best,
-- 
Josselin Poiret

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Maxime Devos]

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

Josselin Poiret schreef op wo 30-03-2022 om 17:17 [+0200]:
> Following a report on IRC [1] that nss-certs wouldn't cross-build, I
> found out that the old syntax of using %output instead of the shinier
> $output was still supported only when native-compiling, and not when
> cross-compiling, at least for build-systems inheriting from gnu.

This is a bit of a distraction from the main point of this e-mail, but
nss-certs is architecture-independent, so you could add '#:target
#false' to 'arguments'.  Then the native compilation code is run
instead of the cross-compilation code, and the same derivation as for
native compilation is reused, saving a little build time (and disk
space, in case nars are generated or deduplication is disabled).

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Maxime Devos]

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

Josselin Poiret schreef op wo 30-03-2022 om 17:17 [+0200]:
> This means that packages that were not updated to fit the new style
> should all fail to cross-compile.  This simple bug could be resolved by
> adding %output to gnu-cross-build, however as was argued on IRC this is
> now undocumented behaviour and we'd rather switch all packages to the
> new style instead.  While I 100% agree with this, I think we should have
> a uniform deprecation policy for this matter, and that there shouldn't
> be such a disparity between cross and native builds.
> 
> What do you all think?

Not sure how this deprecation would look like (a NEWS entry, a blog
post, a (lowercase) news entry, a linter detecting %output, ...), but I
agree with (eventually) removing %output / %outputs whether cross-
compilation or not and for all build systems.  More generally, I agree
that disparity between cross and native builds would ideally be
minimised (I consider native builds to be a special case of cross
builds where one can run the compiled binaries and run tests).

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Ludovic Courtès]

Hi Josselin,

Josselin Poiret <dev@jpoiret.xyz> skribis:

> Looking at guix/build-system/gnu.scm [2], we have gnu-build
> vs. gnu-cross-build, which are responsible for native vs. cross-builds.
> The former uses with-build-variables to set the legacy build variables
> such as %output and %outputs (see the def in guix/gexp.scm), whereas the
> latter does not, only doing so manually and so omitting %output.

‘%output’ (singular) had long been informally deprecated in favor of
‘%outputs’ (plural).

> This means that packages that were not updated to fit the new style
> should all fail to cross-compile.  This simple bug could be resolved by
> adding %output to gnu-cross-build, however as was argued on IRC this is
> now undocumented behaviour and we'd rather switch all packages to the
> new style instead.  While I 100% agree with this, I think we should have
> a uniform deprecation policy for this matter, and that there shouldn't
> be such a disparity between cross and native builds.

The easiest change is to replace:

  %output

with:

  (assoc-ref %outputs "out")

It’s a simple search-and-replace.

The next step would be to use gexps and #$output, but that can be done
incrementally over time IMO.

WDYT?

Thanks,
Ludo’.

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Daniel Meißner]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> The easiest change is to replace:
>
>   %output
>
> with:
>
>   (assoc-ref %outputs "out")
>
> It’s a simple search-and-replace.
>
> The next step would be to use gexps and #$output, but that can be done
> incrementally over time IMO.

I have a patch in that direction sitting on
https://issues.guix.gnu.org/54641 and I am wondering if this is the
style that you’re proposing as the next step.  If so, I could provide
some more patches for other packages as well.

I am also wondering: How are multiple outputs handled with gexps and
#$output?

Best

--
Daniel

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Maxime Devos]

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

Daniel Meißner schreef op vr 01-04-2022 om 12:26 [+0200]:
> I am also wondering: How are multiple outputs handled with gexps and
> #$output?

#~(do-stuff #$output:lib #$output:static #$output:bin #$output:doc ...)

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Ludovic Courtès]

Hi,

Daniel Meißner <daniel.meissner-i4k@ruhr-uni-bochum.de> skribis:

> I have a patch in that direction sitting on
> https://issues.guix.gnu.org/54641 and I am wondering if this is the
> style that you’re proposing as the next step.

Yes, overall I suggest migrating to gexps, as suggested in:

  https://guix.gnu.org/en/blog/2021/the-big-change/

> If so, I could provide some more patches for other packages as well.

Those would be much welcome, though I think there’s no rush either.
Personally, I consider it higher priority to remove input labels than to
convert every ‘arguments’ field.

Thank you!

Ludo’.