guix-patches
[Top][All Lists]
Advanced

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

[bug#56771] [PATCH 00/33] *** Update Jami to 20220725, core Qt packages


From: Maxim Cournoyer
Subject: [bug#56771] [PATCH 00/33] *** Update Jami to 20220725, core Qt packages along the way
Date: Sat, 06 Aug 2022 00:56:19 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

> On 01-08-2022 17:39, Maxim Cournoyer wrote:
>
>> We could also refrain from introducing this argument, instead finding
>> the qtbase in use via search-input-file at the place where we need to
>> know its store output to figure out the version used; that'd be simpler,
>> but would remove the mechanism here that allows a user potentially
>> mixing qt5 and qt6 (probably not a very useful use case) and being able
>> to explicitly set the qtbase used for wrapping/building.
>>
>> What do you think?
>
> Aside from the #$ / #+ the fix looks good to me, but I don't know
> about arguments like #:qtbase, it's not something I've experimented
> with myself.

Apologies, I think your comment about me changing #$ to #+ fell into the
cracks.  I made that change because qtbase was added as a build-inputs
(meaning, native input), as it provides tools that need to run on the
host, such as qmake.  But you are right that Qt programs link to its
libraries, and thus a second qtbase would need to be added to host
inputs for cross-compilation. We should add qtbase there too, but it'd
be nice to confirm cross-compilation can work.

Thanks,

Maxim





reply via email to

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