build-systems: inconsistent use of standard-packages

  • Open
  • quality assurance status badge
Details
2 participants
  • Hartmut Goebel
  • Maxime Devos
Owner
unassigned
Submitted by
Hartmut Goebel
Severity
normal
H
H
Hartmut Goebel wrote on 9 Apr 2022 18:24
(name . bug-guix)(address . bug-guix@gnu.org)
73a4b99c-23db-ac72-2a09-1c454dc1b3e5@crazy-compilers.com
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@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
M
M
Maxime Devos wrote on 9 Apr 2022 19:52
27c029b24af9da1871ad95d1fbfd1dec86a4e9d2.camel@telenet.be
Hartmut Goebel schreef op za 09-04-2022 om 18:24 [+0200]:
Toggle quote (6 lines)
> 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.

Toggle quote (4 lines)
> [...]
> 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.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYlHH8BccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7q6ZAQD2hR39G4nDAy5EM4aC27A4hPnh
EqbyqybG4EWQOjOWnwD/f7kcO2WX4O0RwWcTFBKW/94uhhiPQnWZ89JheVLyrAA=
=XoNg
-----END PGP SIGNATURE-----


?