all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: muradm <mail@muradm.net>
Cc: 57430@debbugs.gnu.org,
	Tobias Kortkamp <tobias.kortkamp@gmail.com>,
	Liliana Marie Prikler <liliana.prikler@gmail.com>
Subject: [bug#57430] [PATCH] gnu: wayland-protocols: Fix cross-compilation
Date: Fri, 26 Aug 2022 20:58:51 +0200	[thread overview]
Message-ID: <9733f5e2-ffc9-b81e-5806-2536c02246bd@telenet.be> (raw)
In-Reply-To: <87bks7x744.fsf@muradm.net>


[-- Attachment #1.1.1: Type: text/plain, Size: 2509 bytes --]


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.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

  reply	other threads:[~2022-08-26 18:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 10:14 [bug#57430] [PATCH] gnu: wayland-protocols: Fix cross-compilation Tobias Kortkamp
2022-08-26 15:04 ` Maxime Devos
2022-08-26 16:59   ` muradm
2022-08-26 18:58     ` Maxime Devos [this message]
2022-08-26 19:22       ` Liliana Marie Prikler
2022-08-26 20:34         ` Maxime Devos
2022-08-27 10:40       ` Tobias Kortkamp
2022-08-27 11:02         ` Maxime Devos
2022-08-30  7:18 ` bug#57430: " Mathieu Othacehe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9733f5e2-ffc9-b81e-5806-2536c02246bd@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=57430@debbugs.gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=mail@muradm.net \
    --cc=tobias.kortkamp@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.