unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: M <maximedevos@telenet.be>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>,
	"48849@debbugs.gnu.org" <48849@debbugs.gnu.org>
Subject: [bug#48849] [PATCH core-updates]: Add #:sh argument towrap-qt-program
Date: Sun, 21 Jan 2024 00:04:57 +0100	[thread overview]
Message-ID: <20240121000457.dB4w2B0081cshW701B4xZR@laurent.telenet-ops.be> (raw)
In-Reply-To: <87a5ozd4nh.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3167 bytes --]

>> Subject: [PATCH 1/8] qt-utils: Allow overriding the shell interpreter in
>>  'wrap-qt-program'.
>>
>> * guix/build/qt-utils.scm (wrap-qt-program): Introduce a #:sh keyword
>>   argument and pass it to 'wrap-program'.
>
> If bash-minimal is added to inputs as we do for other packages making
> use of wrap-program, we don't need to do more, no?  Why do we need to
> explicit the argument here?

Post-hoc reason (for the first patch): wrap-program has #:sh argument, wrap-qt-program doesn’t, which is inconsistent.

For the rest (to be clear I think the remaining patches can be removed):

Right, technically we don’t. The reason is to make sure that it’s the bash from inputs instead of the bash native-inputs. Currently, at first it gets the (wrong) native bash, and later on this is fixed up by the patch-shebangs phase, IIRC.

However, (IIRC) that behaviour is a bug – patch-shebangs is for /usr/bin/… -> /gnu/store/… stuff – if the code “make install” or the like already set a proper /gnu/store/… shebang, why automatically change it to something else? Presumably it set it to the right interpreter, and now patch-shebangs might autocorrupt it.

Another problem: there might not even be a patch-shebangs phase, uses of wrap-program, wrap-qt-program and the phase of the qt-build-system that uses wrap-qt-program (IIRC there exists such a phase) should be usable in isolation. Also, there is a hidden assumption that the uses of wrap-program are _before_ the shebang patching, whereas it might be run afterwards as wll.

Instead, I think it’s better for the uses of ‘wrap-program’ to directly set it to the _right_ bash.
That’s what the #:sh argument is for, but #:sh is set to by default (which “bash”), which is incorrect. Hence, #:sh needs to be set explicitly, and hence wrap-qt-program needs a #:sh argument or the like to pass on to wrap-program.

That said, I don’t think all this explicit #:sh is appropriate either – it would need to be repeated for every single package definition refering to wrap-program, etc.. Instead, for the future, I’d propose to eliminate the argument list of phases, turning phase procedures in phase thunks and stuffing the old arguments in parameter objects instead.

Then, the #:sh of ‘wrap-program’ could default to (search-input-file (inputs) “bin/inputs”) – automatically correct (without needing patch-shebangs) both for native and cross-compilation, and when cross-compiling without “bash” in (implicit) inputs, it automatically errors out (instead of doing the wrong thing as done currently).

The phases would also be a bit less verbose to write – (lambda* (#:key this that #:allow-other-keys) (proc this) stuff …) could become (lambda () (proc) stuff …).

(The ‘procedure’ syntax (inputs) for parameter objects might not be the best here, but that’s nothing some bikeshedding over the precise syntax can’t fix.)

Bst regards,
Maxime Devos

(p.s. I received the mails for the other patches but I’m not responding at the time – not active with Guix currently, and borrowing another computer because of repairs.)

[-- Attachment #2: Type: text/html, Size: 7478 bytes --]

  reply	other threads:[~2024-01-20 23:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-05 11:49 [bug#48849] [PATCH core-updates]: Add #:sh argument to wrap-qt-program Maxime Devos
2024-01-20 22:24 ` Maxim Cournoyer
2024-01-20 23:04   ` M [this message]
2024-01-22  4:58     ` Maxim Cournoyer
2024-01-22  5:12 ` bug#48849: " Maxim Cournoyer

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=20240121000457.dB4w2B0081cshW701B4xZR@laurent.telenet-ops.be \
    --to=maximedevos@telenet.be \
    --cc=48849@debbugs.gnu.org \
    --cc=maxim.cournoyer@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).