GNU bug report logs - #54820
build-systems: inconsistent use of standard-packages

Previous Next

To reply to this bug, email your comments to 54820 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Hartmut Goebel <h.goebel <at> crazy-compilers.com>
To: bug-guix <bug-guix <at> gnu.org>
Subject: build-systems: inconsistent use of standard-packages
Date: Sat, 9 Apr 2022 18:24:55 +0200

Build-systems are adding „@(standard-packages)“ inconsistently to 
„host-packages“ or „build-packages”. For one developing a new 
build-system it is not clear which is the correct form.

Some (e.g. texlive, ruby, python) add it to „host-inputs“)

         (host-inputs `(,@(if source
                              `(("source" ,source))
                              '())
                        ,@inputs
                         ;; Keep the standard inputs of 'gnu-build-system'.
                         ,@(standard-packages)))

Some add it to „build-inputs (e.g. gnu, cmake, qt):

    (build-inputs `(,@(if source
                          `(("source" ,source))
                          '())
                    ,@`(("cmake" ,cmake))
                    ,@native-inputs
                    ,@(if target
                          ;; Use the standard cross inputs of
                          ;; 'gnu-build-system'.
                          (standard-cross-packages target 'host)
                          '())
                    ;; Keep the standard inputs of 'gnu-build-system'.
                    ,@(standard-packages)))


Expected:

Either

a) review and align the code of all build-systems, or

b) add a comment to every build-system briefly explaining why in host 
resp. build-packages here,

c) document how and why to use which form.

Since as far as I've seen there is no detailed „How to write a 
build-system“, developers (well, me :-) tend to develop new 
build-systems based on existing ones. Thus (a) or (b) seem the easier 
and quicker solution.


Reproduce:

grep -A5 -B5 standard-packages guix/build-system/*.scm

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel <at> crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Message #8 received at 54820 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Hartmut Goebel <h.goebel <at> crazy-compilers.com>, 54820 <at> debbugs.gnu.org
Subject: Re: bug#54820: build-systems: inconsistent use of standard-packages
Date: Sat, 09 Apr 2022 19:52:48 +0200

[Message part 1 (text/plain, inline)]

Hartmut Goebel schreef op za 09-04-2022 om 18:24 [+0200]:
> Build-systems are adding „@(standard-packages)“ inconsistently to 
> „host-packages“ or „build-packages”. For one developing a new 
> build-system it is not clear which is the correct form.
> 
> Some (e.g. texlive, ruby, python) add it to „host-inputs“)

FWIW, the latest version of <https://issues.guix.gnu.org/54471>
corrects it for font-build-system.

> [...]
> Some add it to „build-inputs (e.g. gnu, cmake, qt):
> [...]

The reason in cross-compilation support:

  * host-inputs ≈ inputs  
  * build-inputs ≈ native-inputs 

There's also this comment from (guix build-system)

  ;; Here we use build/host/target in the sense of the GNU tool chain (info
  ;; "(autoconf) Specifying Target Triplets").
  (build-inputs  bag-build-inputs        ;list of packages
                 (default '()))
  (host-inputs   bag-host-inputs         ;list of packages
                 (default '()))

And (autoconf)Specifying Target Triplets:

'--build=BUILD-TYPE'
     the type of system on which the package is being configured and
     compiled.  It defaults to the result of running 'config.guess'.
     Specifying a BUILD-TYPE that differs from HOST-TYPE enables
     cross-compilation mode.

'--host=HOST-TYPE'
     the type of system on which the package runs.  By default it is the
     same as the build machine.  Specifying a HOST-TYPE that differs
     from BUILD-TYPE, when BUILD-TYPE was also explicitly specified,
     enables cross-compilation mode.

(standard-packages) contains a tar, gzip, awk ... which are typically only
needed as native-inputs, so they go in 'build-inputs'.

There's also the complication that the cross-compilation system of glibc
is apparently different from other packages:

    ;; The cross-libc is really a target package, but for bootstrapping
    ;; reasons, we can't put it in 'host-inputs'.  Namely, 'cross-gcc' is a
    ;; native package, so it would end up using a "native" variant of
    ;; 'cross-libc' (built with 'gnu-build'), whereas all the other packages
    ;; would use a target variant (built with 'gnu-cross-build'.)
    (target-inputs (if (and target implicit-cross-inputs?)
                       (standard-cross-packages target 'target)
                       '()))

Also, (standard-packages) only contains a non-cross-compiling gcc, so
(standard-cross-packages) (used when cross-compiling) adds a cross-compiling
gcc.

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Message #13 received at 54820-close <at> debbugs.gnu.org (full text, mbox):

From: Hartmut Goebel <h.goebel <at> crazy-compilers.com>
To: 54820-close <at> debbugs.gnu.org
Subject: build-systems: inconsistent use of standard-packages
Date: Wed, 31 Dec 2025 14:26:05 +0100

Moved to https://codeberg.org/guix/guix/issues/5266

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.