Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Le sam. 16 déc. 2023 à 15:46, Lisandro Damián Nicanor Pérez Meyer a écrit : > The cleanest way is to use CMake, as it can handle this directly in > code. And I guess qmake will probably not be a thing for Qt 7. > Thanks. This just works(TM) for two packages.
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Hi, On Wed, 13 Dec 2023 at 15:04, Salvo Tomaselli wrote: > > > This is also being used in src:explosive-c4 now and the approach breaks > > cross compilation. Please stop doing this, we'll have to touch all of > > these. > > > > Still the use case is real and we need a better way to build packages > > with qmake6. I was talking with Sune and Lisandro on IRC and their > > consensus seems to have been that qtchooser and QT_SELECT are dead and > > should not be used for Qt6. They suggested that we add add a new > > --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not > > have qmake6? While changing QT_SELECT from qt5 to qt6 would be > > convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough, > > no? The qmake6 build system can reuse qmake just like qmake_qt4 and > > doing it that way immediately makes cross compilation just work (since > > we already have -qmake6). Lisandro requested naming it qmake6 > > rather than qmake_qt6. Even though this breaks consistency with earlier > > use in debhelper, the similarity to how upstream calls it more > > important. > > > > Salvo and Alexandre, do you second this? > > It would be fine by me, I hope it should be cleaner than how it was to go from > 4 to 5. The cleanest way is to use CMake, as it can handle this directly in code. And I guess qmake will probably not be a thing for Qt 7. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Hej, Am Montag, 11. Dezember 2023, 16:30:14 CET schrieb Helmut Grohne: [...] > Can I also get some ack from Qt maintainers such that we can move > forward in consensus? +1 And thanks for all the work you put in. -- Med vänliga hälsningar Patrick Franz
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
> This is also being used in src:explosive-c4 now and the approach breaks > cross compilation. Please stop doing this, we'll have to touch all of > these. > > Still the use case is real and we need a better way to build packages > with qmake6. I was talking with Sune and Lisandro on IRC and their > consensus seems to have been that qtchooser and QT_SELECT are dead and > should not be used for Qt6. They suggested that we add add a new > --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not > have qmake6? While changing QT_SELECT from qt5 to qt6 would be > convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough, > no? The qmake6 build system can reuse qmake just like qmake_qt4 and > doing it that way immediately makes cross compilation just work (since > we already have -qmake6). Lisandro requested naming it qmake6 > rather than qmake_qt6. Even though this breaks consistency with earlier > use in debhelper, the similarity to how upstream calls it more > important. > > Salvo and Alexandre, do you second this? It would be fine by me, I hope it should be cleaner than how it was to go from 4 to 5. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.codeberg.page/ signature.asc Description: This is a digitally signed message part.
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
--buildsystem=qmake6 is perfect Le lun. 11 déc. 2023, 18:32, Sune Stolborg Vuorela a écrit : > > > +1 from me. qtchooser is no longer supported for Qt >= 6, so going > > > this way is just awesome. > > > > Many thanks > > to Helmut for this. > > Agreed. Both to approach and to thanks to Helmut Thanks for coming up with this solution
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
On Monday, December 11, 2023 5:26:14 PM CET Lisandro Damián Nicanor Pérez Meyer wrote: > > +1 from me. qtchooser is no longer supported for Qt >= 6, so going > > this way is just awesome. > > Also worth to mention: this is something I should have done myself, > but I currently lack the needed time, so Helmut took over. Many thanks > to Helmut for this. Agreed. Both to approach and to thanks to Helmut /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Hi again, On Mon, 11 Dec 2023 at 13:20, Lisandro Damián Nicanor Pérez Meyer wrote: > [snip] > > Can I also get some ack from Qt maintainers such that we can move > > forward in consensus? > > > +1 from me. qtchooser is no longer supported for Qt >= 6, so going > this way is just awesome. Also worth to mention: this is something I should have done myself, but I currently lack the needed time, so Helmut took over. Many thanks to Helmut for this. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Hi, On Mon, 11 Dec 2023 at 12:30, Helmut Grohne wrote: > > Hi, > > On Mon, Dec 04, 2023 at 10:58:44AM +0100, Salvo Tomaselli wrote: > > I use this in my rules when using qt6 > > > > > > %: > > dh $@ > > > > override_dh_auto_configure: > > ln -s /usr/bin/qmake6 ./qmake > > PATH=`pwd`:$(PATH) dh_auto_configure > > > > override_dh_auto_clean: > > $(RM) qmake > > dh_auto_clean > > This is also being used in src:explosive-c4 now and the approach breaks > cross compilation. Please stop doing this, we'll have to touch all of > these. > > Still the use case is real and we need a better way to build packages > with qmake6. I was talking with Sune and Lisandro on IRC and their > consensus seems to have been that qtchooser and QT_SELECT are dead and > should not be used for Qt6. They suggested that we add add a new > --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not > have qmake6? While changing QT_SELECT from qt5 to qt6 would be > convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough, > no? The qmake6 build system can reuse qmake just like qmake_qt4 and > doing it that way immediately makes cross compilation just work (since > we already have -qmake6). Lisandro requested naming it qmake6 > rather than qmake_qt6. Even though this breaks consistency with earlier > use in debhelper, the similarity to how upstream calls it more > important. > > Salvo and Alexandre, do you second this? > > Can I also get some ack from Qt maintainers such that we can move > forward in consensus? +1 from me. qtchooser is no longer supported for Qt >= 6, so going this way is just awesome. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Hi,
On Mon, Dec 04, 2023 at 10:58:44AM +0100, Salvo Tomaselli wrote:
> I use this in my rules when using qt6
>
>
> %:
> dh $@
>
> override_dh_auto_configure:
> ln -s /usr/bin/qmake6 ./qmake
> PATH=`pwd`:$(PATH) dh_auto_configure
>
> override_dh_auto_clean:
> $(RM) qmake
> dh_auto_clean
This is also being used in src:explosive-c4 now and the approach breaks
cross compilation. Please stop doing this, we'll have to touch all of
these.
Still the use case is real and we need a better way to build packages
with qmake6. I was talking with Sune and Lisandro on IRC and their
consensus seems to have been that qtchooser and QT_SELECT are dead and
should not be used for Qt6. They suggested that we add add a new
--buildsystem to debhelper. We already have qmake_qt4 and qmake, why not
have qmake6? While changing QT_SELECT from qt5 to qt6 would be
convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough,
no? The qmake6 build system can reuse qmake just like qmake_qt4 and
doing it that way immediately makes cross compilation just work (since
we already have -qmake6). Lisandro requested naming it qmake6
rather than qmake_qt6. Even though this breaks consistency with earlier
use in debhelper, the similarity to how upstream calls it more
important.
Salvo and Alexandre, do you second this?
Can I also get some ack from Qt maintainers such that we can move
forward in consensus?
Helmut
diff --minimal -Nru debhelper-13.11.8/debian/changelog
debhelper-13.11.9/debian/changelog
--- debhelper-13.11.8/debian/changelog 2023-11-15 09:10:26.0 +0100
+++ debhelper-13.11.9/debian/changelog 2023-12-11 16:21:08.0 +0100
@@ -1,3 +1,9 @@
+debhelper (13.11.9) UNRELEASED; urgency=medium
+
+ * Add the qmake6 build system. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 11 Dec 2023 16:21:08 +0100
+
debhelper (13.11.8) unstable; urgency=medium
* Team upload.
diff --minimal -Nru
debhelper-13.11.8/lib/Debian/Debhelper/Buildsystem/qmake6.pm
debhelper-13.11.9/lib/Debian/Debhelper/Buildsystem/qmake6.pm
--- debhelper-13.11.8/lib/Debian/Debhelper/Buildsystem/qmake6.pm
1970-01-01 01:00:00.0 +0100
+++ debhelper-13.11.9/lib/Debian/Debhelper/Buildsystem/qmake6.pm
2023-12-11 16:20:28.0 +0100
@@ -0,0 +1,15 @@
+package Debian::Debhelper::Buildsystem::qmake6;
+
+use strict;
+use warnings;
+use parent qw(Debian::Debhelper::Buildsystem::qmake);
+
+sub DESCRIPTION {
+ "qmake for QT 6 (*.pro)";
+}
+
+sub _qmake {
+ return 'qmake6';
+}
+
+1
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Thanks you It did the work for one game but I'm now stuck further with two other games: qmake6 complains it can't parse the parameters it get and install newer qmake6 from experimental remove other needed stuff. I want to give it a try to build this with the new debputy, and see what it takes to get it working. deputy is a new debhelper remake / replacement. I think these games are good candidates because they will likely never need a backport to bookworm. The games: - xaos: ok - hexalate: ko - icebreaker: ko - peg-e: ko Le lun. 4 déc. 2023 à 10:58, Salvo Tomaselli a écrit : > > I use this in my rules when using qt6 > > > %: > dh $@ > > override_dh_auto_configure: > ln -s /usr/bin/qmake6 ./qmake > PATH=`pwd`:$(PATH) dh_auto_configure > > override_dh_auto_clean: > $(RM) qmake > dh_auto_clean
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Package: debhelper
Version: 13.11.8
Severity: normal
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org
Hi,
While packaging "xaos" I found out Qt6 integration in debhelper
is not yet quite ready.
The debian/rules is absolute barebones:
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> export QT_SELECT=qt6
>
> %:
>dh $@
Yet it fails, when patching qmake.pm by adding a single "6",
it justs works.
Could qmake.pm be made to use "qmake6" when QT_SELECT=qt6 ?
Greetings,
--- /tmp/qmake.pm 2023-12-03 23:45:47.649530519 +0100
+++ /usr/share/perl5/Debian/Debhelper/Buildsystem/qmake.pm 2023-12-03
23:44:10.180965057 +0100
@@ -97,7 +97,7 @@
if (is_cross_compiling()) {
return dpkg_architecture_value("DEB_HOST_GNU_TYPE") .
"-qmake";
}
- return 'qmake';
+ return 'qmake6';
}
1
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages debhelper depends on:
ii autotools-dev20220109.1
ii dh-autoreconf20
ii dh-strip-nondeterminism 1.13.1-1
ii dpkg 1.22.1
ii dpkg-dev 1.22.1
ii dwz 0.15-1
ii file 1:5.45-2
ii libdebhelper-perl13.11.8
ii libdpkg-perl 1.22.1
ii man-db 2.12.0-1
ii perl 5.36.0-10
ii po-debconf 1.0.21+nmu1
debhelper recommends no packages.
Versions of packages debhelper suggests:
pn dh-make
-- no debconf information
