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


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 54820@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 54820
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch