Sun 19 Feb 2017 12:40:35 AM UTC, comment #24:
Changed to Fixed. John D. was the one who had a reproducible test case and this worked for him.
|
Sat 18 Feb 2017 02:04:58 PM UTC, comment #23:
Pushed http://hg.savannah.gnu.org/hgweb/octave/rev/8db35b1a4f63
|
Sat 18 Feb 2017 02:35:10 AM UTC, comment #22:
OK, could you go ahead and push it?
Thanks.
|
Fri 17 Feb 2017 04:50:20 PM UTC, comment #21:
This is working for me (attached)
(file #39776)
|
Thu 16 Feb 2017 09:48:39 PM UTC, comment #20:
I guess I'm not clearing the right variables here because it looks like it is still picking up cached values.
|
Thu 16 Feb 2017 08:58:37 PM UTC, comment #19:
Same issue:
|
Thu 16 Feb 2017 08:05:17 PM UTC, comment #18:
Does the attached patch avoid the problem noted in comment #15?
(file #39765)
|
Thu 16 Feb 2017 07:58:04 PM UTC, comment #17:
Hmm, it is not supposed to be possible to get a select a mixture of TOOL-qt4 and TOOL-qt5 tools. Let me see if I can spot the error in logic there...
|
Thu 16 Feb 2017 07:49:14 PM UTC, comment #16:
With a quick look on this machine, I don't have a lrelease-qt5 installed.
|
Thu 16 Feb 2017 07:47:02 PM UTC, comment #15:
On machine I am next to at the moment:
|
Thu 16 Feb 2017 04:18:56 PM UTC, comment #14:
Updating to "Works for Me". Following the procedure in comment #13, I used configure with no options (specifically not --with-qt) and I end up with a build properly configured for Qt5.
This is the same result as I got when I specifically used --with-qt=5 in comment #12.
@John D.: Can you post the summary result of configure when it gets it wrong so we can see which test is failing?
|
Wed 15 Feb 2017 08:08:54 PM UTC, comment #13:
sorry typo
Should have been: If I select --with-qt=4 it detects all qt4 versions ok.
Without specifying a version, it was detecting a mix
|
Wed 15 Feb 2017 07:44:35 PM UTC, comment #12:
@John D.: Is comment #8 still accurate that using '--with-qt4' produces a mixture of Qt4 and Qt5 tools?
I have both versions of Qt installed and when I configure with qt4 I get:
When configuring with qt5 I get:
This works for me (Ubuntu 15.10).
|
Sat 11 Feb 2017 02:53:53 AM UTC, comment #11:
ignore comment #10 - wrong bug report :)
|
Sat 11 Feb 2017 02:41:10 AM UTC, comment #10:
It looks like a separate package we do not currently include in mxe.
https://code.qt.io/cgit/qt/qtchooser.git/
How about adding QTCHOOSER=none to the configure call in default-octave.mk ?
|
Sat 11 Feb 2017 02:15:29 AM UTC, comment #9:
Also, if qtchooser is found, should it also use it for selecting the tool and version ?
MOC='qtchooser -run-tool=moc -qt=5'
etc ?
|
Fri 10 Feb 2017 01:13:54 AM UTC, comment #8:
WIth the current code (including this changeset) I end up with a mix of qt5 and qt4 tools selected.
If I select --with-qt=4 it detects all qt5 versions ok.
Should $MOC_QTVER etc all be set to "" each time before checking for the tool to prevent any partial find previously made from being used?
|
Sun 05 Feb 2017 06:54:14 PM UTC, comment #7:
I checked in the following changeset. Does this fix the problem for you?
http://hg.savannah.gnu.org/hgweb/octave/rev/80a2434ba83c
|
Sat 04 Feb 2017 01:23:31 AM UTC, comment #6:
I forgot to mention that nothing installs qtchooser by default on Fedora. On Debian, if you install either Qt 4 or Qt 5 development packages, you get qtchooser automatically. On Fedora, you have to explicitly choose to install the qtchooser package, it is not pulled in as part of any installation tasks or as a dependency of any other packages. So it's safe to say that qtchooser basically doesn't exist for Fedora users.
|
Sat 04 Feb 2017 01:09:10 AM UTC, comment #5:
Correct, on a typical Fedora system,
Qt 4 development packages provide
- /usr/bin/lrelease-qt4
- /usr/bin/moc-qt4
- /usr/bin/rcc
- /usr/bin/uic-qt4
Qt 5 development packages provide
- /usr/bin/lrelease-qt5
- /usr/bin/moc-qt5
- /usr/bin/rcc-qt5
- /usr/bin/uic-qt5
The qtchooser package provides
- /usr/lib/qtchooser/lrelease
- /usr/lib/qtchooser/moc
- /usr/lib/qtchooser/rcc
- /usr/lib/qtchooser/uic
and a shell snippet that adds /usr/lib/qtchooser to PATH.
|
Sat 04 Feb 2017 12:51:54 AM UTC, comment #4:
Having qtchooser or not would only affect the FLAGS variables as far as I can tell.
But I now see how this could fail:
Is the OP's system missing at least one of lrelease, moc, or uic? The configure script assumes that if any of the programs are installed without the -qtN suffix, then all are installed without them. But if (for example) you only have uic-qt4 but no uic, then the test will fail.
I suppose it can be fixed so they are all handled individually, but I don't know whether that will screw something else up on systems that have more than one version installed. I guess it may require being more careful about invalidating all the variables and cache variables defined by this macro if it doesn't succeed completely.
|
Fri 03 Feb 2017 09:10:01 PM UTC, comment #3:
I think this is without qtchooser. Qt 4 installs its programs as symlinks in /usr/bin/ as lrelease-qt4, moc-qt4, uic-qt4, but no rcc-qt4. This appears to me to be the same on either Debian or Fedora. The part that is different is that Fedora installs a symlink /usr/bin/rcc which points to Qt 4's rcc, while that simply doesn't exist on Debian unless you have qtchooser installed.
|
Fri 03 Feb 2017 05:28:28 PM UTC, comment #2:
Do you have qt4 but not qtchooser?
Looking at the configure script, it should be checking for the tools with the "-qt4" suffix, then, if any of those are missing, checking again for the tools without the suffix and using the "-qt4" option if qtchooser is available.
So it seems to me that the configure script should be able to find a mixture of tools with or without the -qt4 suffix and with or without setting the -qt4 option in a FLAGS variable.
I just deleted the qt4 dev tools on my system and I now have uic and uic-qt4 installed (for example), but only rcc. Running configure gives me UIC and RCC set to uic and rcc and UICFLAGS and RCCFLAGS set to -qt4. If I didn't have qtchooser, I would expect empty values for the FLAGS variables, but UIC and RCC still set to uic and rcc.
Is this a caching problem on your system? Do you run configure with the option to generate a cache file? If so, try deleting any old cache file you have.
Did you run bootstrap again after updating? I'm not sure whether that's the issue, but when strange things happen with configure and the development sources, my first step is to start fresh.
If it still fails for you, then I need more info to understand how this can fail, or you need to debug it and find where the logic is going wrong because I can't duplicate it on my system.
If you want to send more info, then you can run the configure script with "/bin/bash -xv" and extract the relevant parts of the output (there will be a lot of it).
|
Fri 03 Feb 2017 12:23:07 AM UTC, comment #1:
Another possible workaround might be to ensure the Qt bin directory for the version of Qt you want is preferred via PATH search, e.g.
Can you test whether that works for you (without setting RCC_QTVER)?
I agree with your observation that Qt 4 does not include rcc as rcc-qt4, while Qt 5 does, and this just makes configuring these tools a continual challenge. It would be nice to make this work, but without breaking what we have, and what we fixed with the change you quote, any suggestions?
|
Thu 02 Feb 2017 10:08:58 PM UTC, original submission:
On my build system there is moc-qt4, uic-qt4, lrelease-qt4, rcc, but no rcc-qt4.
output of rpm search:
Because there is not rcc-qt4, configure currently does not detect qt.
A work around is to invoke configure specifying RCC_QTVER
|