GNU bug report logs - #56771
[PATCH 00/33] *** Update Jami to 20220725, core Qt packages along the way

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Jack Hill <jackhill <at> jackhill.us>, Lars-Dominik Braun <lars <at> 6xq.net>, 56771 <at> debbugs.gnu.org
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

Hi Maxime,

Maxime Devos <maximedevos <at> 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

Previous Next

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