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.

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)]

Previous Next

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