After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 737174 - No way to build against qt4 if both versions are installed
No way to build against qt4 if both versions are installed
Status: RESOLVED FIXED
Product: libmediaart
Classification: Other
Component: Storage
0.7.x
Other Linux
: Normal normal
: ---
Assigned To: libmediaart maintainer(s)
libmediaart maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-09-23 13:16 UTC by Pacho Ramos
Modified: 2015-05-31 12:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
libmediaart-qt-version-automagic-fix.patch (1.60 KB, patch)
2014-11-02 01:45 UTC, Paweł Stankowski
committed Details | Review

Description Pacho Ramos 2014-09-23 13:16:11 UTC
As configure is automagically switching to qt5 when both are installed, there is no way to force a build against qt4 when qt5 is present.
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies

Thanks
Comment 1 Martyn Russell 2014-09-23 16:30:25 UTC
(In reply to comment #0)
> As configure is automagically switching to qt5 when both are installed, there
> is no way to force a build against qt4 when qt5 is present.
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies

Under what circumstances would you want to use Qt4 when you have Qt5?
Comment 2 Pacho Ramos 2014-09-24 09:24:58 UTC
Well, it's a bit of making it more predictable. I mean, currently, most people will have libmediaart compiled against qt4 because qt5 landed the tree few days ago but, as soon as people starts installing qt5 also, libmediaart will be compiled against qt5 as soon as people tries to recompile it.

I guess that qt5 support is preferred for libmediaart? In that case maybe we could force that dependency and disable qt4 support completely (maybe some people will disagree if qt5 is pulled only by this at this stage... but I guess qt5 will be used by more and more apps and this shouldn't be a major issue)
Comment 3 Martyn Russell 2014-10-19 16:54:23 UTC
(In reply to comment #2)
> Well, it's a bit of making it more predictable. I mean, currently, most people
> will have libmediaart compiled against qt4 because qt5 landed the tree few days
> ago but, as soon as people starts installing qt5 also, libmediaart will be
> compiled against qt5 as soon as people tries to recompile it.

I guess it depends on what is installed in $prefix, but yea.
 
> I guess that qt5 support is preferred for libmediaart? In that case maybe we

There is no preference, basically, we just support both versions to work in both cases.

> could force that dependency and disable qt4 support completely (maybe some
> people will disagree if qt5 is pulled only by this at this stage... but I guess
> qt5 will be used by more and more apps and this shouldn't be a major issue)

Some configure option for this could be added indeed - fancy writing a patch, should be quite simple to do?
Comment 4 Paweł Stankowski 2014-11-02 01:45:57 UTC
Created attachment 289820 [details] [review]
libmediaart-qt-version-automagic-fix.patch

Adds optional configure flag "--with-qt-version=<4|5>" that may be used to enforce qt 4.x or qt 5.x version.
Comment 5 Martyn Russell 2014-11-03 09:13:53 UTC
Comment on attachment 289820 [details] [review]
libmediaart-qt-version-automagic-fix.patch

Looks good to me, please go ahead and commit. If you can't I will. Thanks again!
Comment 6 Priit Laes (IRC: plaes) 2014-11-20 16:53:06 UTC
(In reply to comment #5)
> (From update of attachment 289820 [details] [review])
> Looks good to me, please go ahead and commit. If you can't I will. Thanks
> again!

Martyn, could you go ahead and commit it?
Comment 7 Martyn Russell 2014-11-21 11:10:41 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (From update of attachment 289820 [details] [review] [details])
> > Looks good to me, please go ahead and commit. If you can't I will. Thanks
> > again!
> 
> Martyn, could you go ahead and commit it?

Sure, see comment #5 ;)
Comment 8 Pacho Ramos 2015-05-06 10:42:52 UTC
I am not sure why is this still in NEEDINFO status :/, anyway, would be nice if someone with enough permissions could finally commit it :)

Thanks
Comment 9 Martyn Russell 2015-05-31 12:52:20 UTC
Review of attachment 289820 [details] [review]:

Committed the patch, thanks! :)