Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qtchooser configs #83

Closed
wants to merge 3 commits into from
Closed

qtchooser configs #83

wants to merge 3 commits into from

Conversation

mgorny
Copy link
Member

@mgorny mgorny commented Oct 20, 2014

Based on files used by Arch. Untested on revdeps. Still needs update to Qt eclasses to set QT_SELECT, and maybe an eselect module to control the default.conf (currently not installed).

@mgorny
Copy link
Member Author

mgorny commented Oct 20, 2014

A small update: added QT_SELECT to qt4-r2 so that it always uses Qt4. Tested with x11-misc/synergy.

@mgorny mgorny mentioned this pull request Oct 20, 2014
@Pesa
Copy link
Contributor

Pesa commented Oct 20, 2014

The approach I had in mind was that qt4-r2 and qmake-utils eclasses used the full path to the actual qmake binary in /usr/lib/qt[45]/bin (falling back to /usr/bin/qmake if it doesn't exist, i.e. on Qt < 4.8.6)

@Pesa Pesa self-assigned this Oct 20, 2014
@mgorny
Copy link
Member Author

mgorny commented Oct 20, 2014

Will this handle the other Qt binaries? I'm no expert on this, so I assumed there could be some plain calls to other binaries without reusing the path from qmake call.

@Pesa
Copy link
Contributor

Pesa commented Oct 20, 2014

Everything else should depend on qmake and how qtcore was built (see e.g. qmake -query output). That being said, we know there are broken build systems out there, especially those based on autoconf, but they need to be fixed regardless. Besides, if a packages supports both qt4 and qt5 (e.g. media-libs/phonon), exporting QT_SELECT won't work anyway.

@mgorny
Copy link
Member Author

mgorny commented Oct 20, 2014

And the qt4-r2 eclass won't be of any help, would it? Anyway, how do the first two patches look then?

@Pesa
Copy link
Contributor

Pesa commented Oct 21, 2014

Exactly, autoconf-based (or other broken) build systems don't use qt4-r2, so the export won't help, they need to be fixed regardless.

@mgorny
Copy link
Member Author

mgorny commented Oct 21, 2014

Any news on this one? I think I implemented everything you requested.

@Pesa
Copy link
Contributor

Pesa commented Oct 21, 2014

Sorry I didn't notice you pushed new commits, I have some major issues with github notifications lately... I'll try to review and merge tomorrow at the latest.

@mgorny
Copy link
Member Author

mgorny commented Oct 22, 2014

Hmm, I don't get notifications for your comments either.

And no, we don't have a way to get that. But I don't think that having common does matter here. As your research shows, upstreams can't rely on any consistent naming and we should worry only about having a simple way of selecting the correct version via ebuilds.

I also see that my interpretation of qtchooser/*.conf disagrees with Fedora. I'll look into the sources.

@mgorny
Copy link
Member Author

mgorny commented Oct 22, 2014

Ok, I see that Fedora is wrong and the second line is supposed to be 'library path' rather than 'prefix'. So my patch is fine :).

@mgorny
Copy link
Member Author

mgorny commented Oct 25, 2014

Ping!

@Pesa
Copy link
Contributor

Pesa commented Oct 26, 2014

pong! sorry...real life...

Pesa added a commit that referenced this pull request Oct 26, 2014
@Pesa
Copy link
Contributor

Pesa commented Oct 26, 2014

Merged with some fixups, thanks a lot!

@Pesa Pesa closed this Oct 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants