[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Maxime Devos
Subject: [bug#57430] [PATCH] gnu: wayland-protocols: Fix cross-compilation
Date: Fri, 26 Aug 2022 20:58:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0

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


Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]