GNU bug report logs - #57430
[PATCH] gnu: wayland-protocols: Fix cross-compilation

Previous Next

Package: guix-patches;

Reported by: Tobias Kortkamp <tobias.kortkamp <at> gmail.com>

Date: Fri, 26 Aug 2022 14:32:02 UTC

Severity: normal

Tags: patch

Done: Mathieu Othacehe <othacehe <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: muradm <mail <at> muradm.net>
Cc: 57430 <at> debbugs.gnu.org, Tobias Kortkamp <tobias.kortkamp <at> gmail.com>, Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: [bug#57430] [PATCH] gnu: wayland-protocols: Fix cross-compilation
Date: Fri, 26 Aug 2022 20:58:51 +0200
[Message part 1 (text/plain, inline)]
On 26-08-2022 18:59, muradm wrote:
> As far as I understand, this one is to reduce dependencies of
> wayland-protocols itself. 

This one keeps the dependencies the same (except for pkg-config / 
pkg-config-for-build) -- it just sorts the dependencies differently.

> As far as I know, there is no binary output of wayland-protocols,

'ls -R "$(guix build wayland-protocols)"'? Maybe not 'binary', but it 
still appears required by some dependents.

> and wayland maybe needed as dependency for testing purposes only. 
This appears confirmed by meson.build. In that case, wayland can be 
removed from 'inputs' and put in 'native-inputs' unconditionally.

Tobias, does unconditionally moving wayland from 'inputs' to 
'native-inputs' (and unconditionally using pkg-config-for-build) work? 
Potential problem: lots of dependents according to "guix refresh -l", 
making it unconditional would need to be done on core-updates or staging.

> IMHO these tests are targeted for developers producing protocol
> specifications. Once protocol specification is ready
> wayland-protocols is released. So running tests on
> wayland-protocols should be pointless waste of resources, as they
> don't prove that anything useful, instead dependents should
> test themselves. If testing causing waste of space and resources
> I would turn them off or probably use copy-build-system even. 
#:tests? #false should suffice, no need to switch to copy-build-system.

I see the argument for a waste of CPU time/energy resources, but not for 
a waste of space.

Also, it is a dangerous assumption to make that developers run tests 
prior to a release. It seems pretty logical to me to do that, but 
sometimes errors are encountered in Guix and discussions happen upstream 
that indicate that this somehow didn't happen.

Even if developers are known to always run tests, without fail, they 
might run tests in a different environment.

For example, until recent-ish, GCC did -fcommon as a default, but later 
switched to -fcommon, breaking some builds.

Also, 'developers' is not necessarily 'upstream developers'. Sometimes 
Guix adds a patch to package definitions, in combinations that upstream 
might not have tested, in that case running tests is important. 
Additionally, sometimes I find it more practical to write a patch, add 
it to the package definition and do a "guix build", than to do 
whatever's the meson equivalent of 'make && make check'.

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]

This bug report was last modified 2 years and 323 days ago.

Previous Next


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