qt5-mac

[ecbrown (Eric Brown)]

Qt5 is in RC2, and I would like request that a qt5-mac be created and maintained.

[mf2k (Frank Schima)]

Ideally we should call this port "qt5" instead of "qt5-mac".

[ryandesign (Ryan Carsten Schmidt)]

Or "Qt5".

[michaelld (Michael Dickens)]

Yes, I think "qt5" is fine. I have a bit of a queue before I get to this, so if anyone else wants to give it a whirl that's fine by me. But, I should be able to get there in a few weeks if nobody else does.

[mparchet@…]

Hello,

qt 5.0 is out

See this link :

​http://qt-project.org/downloads

Can you make a package called qt5-mac ?

Best regards

mparchet

[mparchet@…]

Cc Me!

[macports@…]

Cc Me!

[springermac (Jonathan Springer)]

Cc Me!

[bratchenko@…]

Cc Me!

[crazyhorse671@…]

Cc Me!

[jamesfmarshall@…]

Cc Me!

[mroman@…]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!

[michaelld (Michael Dickens)]

My first cut at getting this port to compile is failing miserably. I think there's a QMake build problem with not internally linking headers for use while compiling Qt5, but I haven't had time to track down the issue; or, maybe not including the correct header search paths. Anyway, I am working on this port, slowly and as my time allows. When I get a chance I will create a branch with this work, so that others might try to do more work on it.

[mparchet@…]

Replying to michaelld@…:

My first cut at getting this port to compile is failing miserably. I think there's a QMake build problem with not internally linking headers for use while compiling Qt5, but I haven't had time to track down the issue; or, maybe not including the correct header search paths. Anyway, I am working on this port, slowly and as my time allows. When I get a chance I will create a branch with this work, so that others might try to do more work on it.

Hello,

I have to try to compile qt 5 published on qt-project website.

I have completely uninstalled the qt4-mac package and compile qt5 manually.

I have this error in make process.

In file included from qcocoaintegration.mm:44:
./qcocoawindow.h:52:28: error: extra qualification on member 'QCocoaWindow'
class QT_PREPEND_NAMESPACE(QCocoaWindow);
                           ^
../../../../include/QtCore/../../src/corelib/global/qglobal.h:84:39: note: 
      expanded from macro 'QT_PREPEND_NAMESPACE'
# define QT_PREPEND_NAMESPACE(name) ::name
                                      ^
1 error generated.

Have you ever had this error when you compiled your qt 5 package for macport ?

If you put your source code on internet, some other people can try to fix the bug.

I would like try to compile it on my mac os 10.8 system.

I need to test qt 5 because I have have a problem with an akonadi plugin.

Tanks for your answer

Best regards

mparchet

[michaelld (Michael Dickens)]

I did get beyond this somehow, but I don't recall how. My build from 3 weeks (or so) ago got trashed. I'll try to rebuild to this point again and see what I can do about posting my work for others to leverage.

[mavaugha@…]

Cc Me!

[gaspard.dhautefeuille@…]

Cc Me!

[gallafent]

Cc Me!

[dcecchin@…]

Cc Me!

[Veence (Vincent)]

Nobody gave it a try recently?

[mojca (Mojca Miklavec)]

Cc Me!

[mroman@…]

qt 5.1 was just released. Is there any hope for qt5 port?

[michaelld (Michael Dickens)]

I haven't tried compiling 5.1 within MacPorts yet. I'm working on updating qt4-mac to 4.8.5 right now.

[nils.hjelte@…]

Cc Me!

[dsdale24@…]

Cc Me!

[NeilGirdhar (Neil)]

Cc Me!

[patrick.sizun@…]

Cc Me!

[kierans (Kieran Simpson)]

Cc Me!

[cooljeanius (Eric Gallager)]

Replying to michaelld@…:

I'm working on updating qt4-mac to 4.8.5 right now.

This was done as of r107841 so presumably you could give qt5 another try now?

[michaelld (Michael Dickens)]

Yes, 4.8.5 got finished and checked in. Qt5 is not a high priority for me, at least right now. Qt4 does everything I need, at least for now. I don't know when I'll find time; been quite busy with work, and Qt are "pro bono" ports for me. Sorry for the downer.

[pixilla (Bradley Giesbrecht)]

michaelld: Thank you for the significant time you have contributed toward maintaining the qt4-mac port.

[hsivank@…]

Replying to mparchet@…:

I have this error in make process.

In file included from qcocoaintegration.mm:44:
./qcocoawindow.h:52:28: error: extra qualification on member 'QCocoaWindow'
class QT_PREPEND_NAMESPACE(QCocoaWindow);
                           ^
../../../../include/QtCore/../../src/corelib/global/qglobal.h:84:39: note: 
      expanded from macro 'QT_PREPEND_NAMESPACE'
# define QT_PREPEND_NAMESPACE(name) ::name
                                      ^
1 error generated.

This has been fixed upstream : ​https://qt.gitorious.org/qt/qt5-maemo5-qtbase/commit/655ba5755696df8e2594bca9f7696ab621f5afc3

[hsivank@…]

Cc Me!

[bonoba@…]

Cc Me!

[petrrr]

Cc Me!

[lynxluna (Didiet)]

Cc Me!

[macports@…]

Cc Me!

[mamoll (Mark Moll)]

Cc Me!

[macports@…]

Cc Me!

[tommaso.vinci@…]

Cc Me!

[tommaso.vinci@…]

Cc Me!

[tommaso.vinci@…]

Cc Me!

[dliessi (Davide Liessi)]

Cc Me!

[seanfarley (Sean Farley)]

I just had a user ask me about py-qt5 and was wondering about the status of this port. Any progress?

[michaelld (Michael Dickens)]

There's a GSoC14 option open for some adventurous student, with me as mentor. I've been loaded with work and haven't had time to look into this; I do not know when I'll have time to work on this given my current work queue. It also does not help that Qt4 works fine for my needs right now; when we start looking at Qt5 then I'll start getting serious about this port if it's not already in place. I assume by the lack of response from anyone else that nobody has either tried or had luck getting this port working.

[larryv (Lawrence Velázquez)]

Cc Me!

[mojca (Mojca Miklavec)]

But it's also true that I haven't heard about any GSOC student being interested in that. (But we'll know that in 11 days, and the final decision in one month.)

I tried to look into it a couple of times, but I'm always stuck at the point where I figure out that there is simply too much work to do to just prepare a basic port, even before bumping into any compile errors. Unless we get a GSOC student work on that, it would be nice if anyone who does anything at least "publishes" the partial work.

I'm currently testing a few things with an external installation of Qt, but it would be really nice to have Qt 5 available in MacPorts.

[michaelld (Michael Dickens)]

I'm going to wait until we hear back from students about GSoC. If there are no takers, I'll find a way to get this into my queue here and there and hopefully piece something together. My "current" effort is so old I don't think it has any value. I agree that if anyone has made progress I'd love to hear about it and see the patches / Portfile / recipe used to get the progress.

[ChristianFrisson (Christian Frisson)]

to be located in the 'files' folder

[ChristianFrisson (Christian Frisson)]

to be located in the 'files' folder

[ChristianFrisson (Christian Frisson)]

Hi,

I attached a Portfile to be located in aqua/qt5 and a script and a config file to be put in the 'files' subdir.

I'm not sure it fits the MacPorts standards, but it works: rather than compiling everything, it downloads the 5.2.1 dmg from the official distribution, mounts it and extracts the 7z files, destroots it following to the qt4-mac file tree (with qt5 replacing qt4 whenever needed), mods the pkgconfig and cmake files accordingly to the adapted paths. It is way faster: once the dmg is downloaded, it takes approx 3 minutes to install. Tested on a macbook pro retina late 2013 15" with OSX 10.9.2.

I could compile modified OpenSceneGraph-devel and opencv Portfiles against it (these use CMake), using a qt5 variant.

I initially made a symlink by hand to make sure mkspecs files can be found by default. I'm not familiar with this, since I use CMake instead of qmake. I couldn't manage that through the qt.conf file, QMAKE_MKSPECS doesn't seem to be settable that way with Qt5 anymore, it seems it is now hardcoded, 'mkspecs' appended to the main qt dir, can't get to find the bug report where I read that. I'm not sure the following code actually works as a replacement:

post-activate {
  system "ln -s ${prefix}/share/qt5/mkspecs ${prefix}/mkspecs"
}

Best regards, Christian

[michaelld (Michael Dickens)]

Interesting idea, Christian. Not quite what we're usually thinking of here in MacPorts world, but if done correctly this could work as an interesting interim solution before "compile from source" works within MacPorts. If anybody tried this method out, I encourage you to post back to this ticket with how it worked for you, successes / failures / etc...

[neverpanic (Clemens Lang)]

The binaries downloaded from upstream will likely

• not work on PPC and maybe other older systems
• not respect the macports configuration values of build_arch and universal_arch
• not link against the MacPorts versions of zlib, openssl, tiff, libpng, libmng and jpeg.

[neverpanic (Clemens Lang)]

What C++ runtime is used by these binaries? If it's libstdc++ that won't work on Mavericks and above, if it's libc++ that might cause problems on older systems. I don't see version-specific binaries.

[michaelld (Michael Dickens)]

Cal makes a good set of points, though the first one is minor since I doubt we'll be able to get Qt5 to compile on PPC; I believe Qt5 will end up being Intel-only, and 10.6+ only. His last point is very true: Qt (4 or 5) embeds these libraries instead of linking with those provided by the system (OSX or MacPorts). For example, Qt5's embedded ​libpng is version 1.5.10, which is not ABI compatible with MacPorts version 1.6.10. I'm downloading the latest 5.2.1 binary right now; since it was compiled using Clang, I believe it will be linked with libc++. Which will be an issue on 10.8 with MacPorts, which uses libstdc++ by default; not a major issue on 10.9.

Anyway: Yes, potential issues therein. I'm not saying this is the best solution. It's an interesting, interim, and imperfect solution for folks desperate to get Qt5 in MacPorts. I do think that, once Qt5 is working in MacPorts properly, that anybody using this interim solution should have little issue upgrading to the actual MacPorts Qt5 -- they should be API and ABI compatible (though, not +uiniversal'ly compatible).

[michaelld (Michael Dickens)]

At least on 10.8, Qt5's libraries links with /usr/lib/libstdc++.6.dylib, among other system libraries.

[mojca (Mojca Miklavec)]

I just wanted to say that Qt 5 works perfectly fine on 10.7. It links against /usr/lib/libstdc++.6.dylib (and also against /usr/lib/libz.1.dylib). But I didn't yet try the attached port.

Just a thought: I had an impression that one can install Qt to an arbitrary location as an option during installation. That could(?) avoid the need for install_name_tool.

[mojca (Mojca Miklavec)]

If anyone wants to test, don't forget to add executable bit to install.sh.

The following folder in destroot also doesn't have sufficient permissions:

./opt/local/share/qt5/examples/ doesn't have sufficient permissions (drwx------)

I don't know if it's easy/possible to completely separate Qt4 and 5, but I would suggest to put libraries to /opt/local/lib/Qt/5/QtSomething rather than to /opt/local/lib/QtSomething to allow side-by-side installation at least to some extent. Same for /opt/local/include and a bunch of other files.

(It will probably be relatively painful to test Qt 5 if it will conflict with Qt 4. Some software is simply nonfunctional with Qt 5. Including one of the ports I maintain.)

[michaelld (Michael Dickens)]

The installer that comes with Qt5 does allow installation into an arbitrary location. All of the library and application linkage matches the new location correctly, so somewhere they must use install_name_tool to change them throughout. That said, I think the "install.sh" script does a pretty thorough job of making this change; and, we need to get the files into the DESTROOT dir first so I don't think using Qt's installer will work in this case. Either way, installing from source will be better once it works.

[mojca (Mojca Miklavec)]

Yes, installing from source would be better. But this looks like a promising and usable first step that will allow us to test software against Qt5 way before someone manages to get Qt5 build working.

I have a lot of ports that depend on Qt4. This is why it would be very helpful if it was possible to install Qt5 side-by-side with Qt4.

It would also be very helpful if we had a draft of a Qt5 Portgroup.

[ChristianFrisson (Christian Frisson)]

Cc Me!

[ChristianFrisson (Christian Frisson)]

Hi,

It would work as an interim for me on a local port source with modified dependents. But I still also have dependents on qt4 not yet ported to qt5 that forces me to stick with qt4.

If separate and side-by-side installations of qt4 and qt5 could be managed, that would require modifying qt4-mac as well, maybe breaking dependents on the way, right?

How would you see it? As follows (with X=4;5)?

• ${prefix}/include/qtX/...
• ${prefix}/share/doc/qtX/...
• ${prefix}/share/qtX/...
• /Applications/MacPorts/QtX/...

But how to deal with binaries? By appending -qtX to each? And pkgconfigs? And Frameworks? And mkspecs?

Another suggestion: I also first tried compiling, but got annoyed to have it fail after several hours, repeatedly. Hence the interim solution. How about making one port per qt library, fetched from gitorious, and a macro port to install them all? Would that help progressively having the whole to compile, step-by-step?

Best regards, Christian

[mojca (Mojca Miklavec)]

I don't think that modifying qt4-mac is a problem. Or rather: if some modifications are needed and can be justified, there will be a way to make them in trunk. And dependents will be revbumped as necessary (if there will be a need for that), just as they are after every other version upgrade.

On the other hand most conflicts could be resolved by leaving Qt 4 files where they are now and by putting Qt 5 files where we want them to be. The Qt 4 files can be moved "to a better place" later as long as they don't cause serious problems.

I would suggest:

• ${prefix}/include/qt/qtX/ (or ${prefix}/include/qt/X/), likewise for lib
• it doesn't really matter for share, it can be either doc/qt/qtX or doc/qtX as long as it's unique (it doesn't break anything at all)
• apps are a separate monster and would cause problems anyway if there are duplicate names at different locations, but your suggestion is ok (we just need to have something to start with)

Binaries: I would suggest putting all the binaries to ${prefix}/libexec/qt/qt5/ and then make symlinks lupdate-5.2, qmake-5.2 etc. in the bin.

I admit that I have no clue what to do with pkg-config. Frameworks can share multiple versions to some extent, but there's always a file Versions/Current that spoils the game – I'm not exactly sure how to solve that problem either other than moving the framework to a different location.

For wxWidgets the solution was to install everything to some obscure location and to make sure that the PortGroup can feed information to one additional configure option to allow the software to find the right version of wxWidgets. If users want to use wxWidgets for their own projects, they are free to use

port select --set wxWidgets wxWidgets-3.0

I would either imagine being able to achieve the same with Qt or to create a "fork", make sure that all projects work with Qt 5 and switch everything to Qt 5 at some point in future.

One (sub)port per qt library sounds fine. I'm not sure how to combine them all together, but if anyone does, it sounds like a good start. One of the very important pieces would also be to start building a new portgroup.

PS: for "projects" like "developing a Qt 5 port", using a distributed VCS would actually help more people test and contribute ideas and code (contrary to what I argued on the mailing list in favour of SVN). But in this case having a temporary repository with just this one port should work just fine.

[nils.hjelte@…]

Cc Me!

[nils.hjelte@…]

Cc Me!

[nils.hjelte@…]

Cc Me!

[hsivank@…]

This is a simple Portfile i use to build qtbase. (tested on Mavericks)

PortSystem	1.0
name		qtbase
categories	devel
version		5.2.1
set branch	[join [lrange [split ${version} .] 0 1] .]
master_sites	http://download.qt-project.org/official_releases/qt/${branch}/${version}/submodules/
distname	qtbase-opensource-src-${version}
distfiles	${distname}.tar.gz
checksums	sha1 4724524d6262ff4a38bb479a36aac2021d7a5af1 \
		rmd160 078963c30492ef6151b1017c4c3638e1c0f824d1

configure.args	-opensource -confirm-license -no-compile-examples -nomake examples -nomake tests -no-xcb -system-zlib -qt-libpng -qt-libjpeg -release \
		-prefix ${prefix}/libexec/qt5/desktop

build.target ""

Includes,libraries, binaries ... are sandboxed inside /opt/local/libexec/qt5/desktop.
This way i can manage other targets like /opt/local/libexec/qt5/ios, /opt/local/libexec/qt5/android ...
I think we can use ​qt4-1.0.tcl as example for Qt5 PortGroup
We *just* need to modify qt_dir (+ some minor fix) ?

[hsivank@…]

Replying to mojca@…:

PS: for "projects" like "developing a Qt 5 port", using a distributed VCS would actually help more people test and contribute ideas and code

+1

[michaelld (Michael Dickens)]

Interesting. It looks like Qt5 is split into parts (called by them "submodules"), or it can be compiled as a single ginormous module (as is done with Qt4). If as submodules, you install qtbase first, then, somehow, the others use that install to build themselves. Seems like a nice way to go, if it really works -- sort of where we started heading with Qt4, but never really got there except a few of the Sql plugins (and, even those have issues).

I played around with qtbase' install a bit today, and, after some tweaking, got it to compile using MacPorts-provided projects. Can't use pre-compiled headers, ICU, glib2, xcb, and a few other projects I don't remember. And, not a surprise, it intermixes libraries and frameworks -- so, those will have to get dealt with .. but, nothing that a nice post-destroot can't handle!

I'll play around with some submodules next week to see how they are compiled / installed. It might be possible to get a qt5 port up and running in stages rather than in one fell swoop, which IMHO would be the better way to go given how big the build is.

[ChristianFrisson (Christian Frisson)]

Nice news about the submodules!

To complement the "port select" idea, I've just noticed that Ubuntu provides a tool called qtchooser: ​https://qt.gitorious.org/qt/qtchooser

"The Qt Chooser provides a wrapper to switch between versions of Qt development binaries when multiple versions like 4 and 5 are installed or local Qt builds are to be used." ​http://manpages.ubuntu.com/manpages/trusty/en/man1/qtchooser.1.html

It allows commands such as:

qtchooser -run-tool=qmake -qt=qt4 <source> -spec <platform>

[hsivank@…]

About the port select.
I think that it could be a good idea to sandbox Qt4 and Qt5 inside their own unique directory instead of ${prefix}. Official installer puts Qt inside /usr/local/Qt/QtX/...
I know that it is not the philosophy of MacPorts but it could really simplify things : no conflicts between Qt4 and Qt5
If a port belongs to QtX portgroup then we just have to add some env variables for the build to succeed (in the same way as ​qt4-1.0.tcl does but qt_dir will be something like ${prefix}/Qt/QtX/)
"port select" should be used to symlink one Qt inside ${prefix} for personal dev purpose.
This is close to ​nix

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[mkae (Marko Käning)]

Cc Me!

[mkae (Marko Käning)]

Don't know whether this homebrew recipe could be useful:

​https://github.com/Homebrew/homebrew/blob/master/Library/Formula/qt5.rb

[michaelld (Michael Dickens)]

Interesting. I didn't know HB had a formula; it's a pretty basic formula; I guess Qt5 is getting more robust compiling on OSX finally! I haven't had time to get back to trying modules yet. Hopefully next week. qtbase seems to build / install nicely, and I'm planning on moving Qt4 into libexec/qt4 (and, Qt5 into libexec/qt5) to keep them separate but installable at the same time (per some comment above; good idea!).

[mkae (Marko Käning)]

Replying to michaelld@…:

I didn't know HB had a formula;

So it was good I posted it then. :)

it's a pretty basic formula; I guess Qt5 is getting more robust compiling on OSX finally!

It looks like it.

Yes, it would indeed be great if one could have both installed in parallel!

[digitalriptide@…]

Cc Me!

[gallafent]

FWIW, and just to make a note here, I have Qt 5.3.0 building and working happily here using the following configure incantation:

configure -sdk macosx10.9 -warnings-are-errors -system-proxies -no-linuxfb -no-directfb \
-no-dbus -pch -optimized-qmake -v -no-compile-examples \
-nomake examples -no-glib -opensource -confirm-license -force-debug-info -debug-and-release \
-prefix ‘(cd ../qt-everywhere-opensource-src-5.3.0-beta-deploy/; pwd -P)‘ -icu -no-xcb \
-I /opt/local/include -L /opt/local/lib

At the moment I haven't tried the final release, but the above worked well for the beta, with the following provisos:

There’s an existing bug[1][2] in Qt 5.3.0 beta which causes problems trying to build for Mac OS 10.7 and later with C++11. We work (force our way) around this by adding the line QMAKE MACOSX DEPLOYMENT TARGET = 10.7 to the file qtbase/mkspecs/macx-clang/qmake.conf so that this configuration parameter propagates everywhere when building with that toolchain with c++11 configured.

There is also another[3], which prevents the enginio component from building. Applying the workaround of altering the value of MODULE VERSION to be 5.3.0, as suggested in that bug, allows the build to complete.

[1] ​https://bugreports.qt-project.org/browse/QTBUG-37803 [2] ​https://bugreports.qt-project.org/browse/QTBUG-31586 [3] ​https://bugreports.qt-project.org/browse/QTBUG-37902

[neverpanic (Clemens Lang)]

Keep in mind that we need a build that uses libc++ on systems >= Mavericks to avoid compatibility problems with all other software using Qt 5. With that background it seems ​https://bugreports.qt-project.org/browse/QTBUG-37803 is a blocker.

With respect to C++11: If Qt 5 needs C++11, don't get your hopes up that it will ever work on systems earlier than Mavericks and with anything but libc++. I wouldn't consider it a huge problem if a potential port doesn't build on anything but Mavericks because of that.

[michaelld (Michael Dickens)]

Why the change of priority from Normal to High, Mojca? Is there truly a dire need for this port ASAP? I'm swamped in work for 3 weeks, then on a much needed vacation for 2 weeks. So, as usual, if somebody else is willing to get this port in place I think that's great. I should have time to work on this come late July / early August -- but, clearly that's not ASAP or "high priority". I'll leave this as High priority, but I hope we reconsider whether this is truly necessary -- and, if so, document why it is.

[mojca (Mojca Miklavec)]

I'm stumbling across software/ports that don't support Qt4 any longer.

Some of functionality of programs (gnuplot in particualar) is totally weird in Qt4 and the same issues are magically fixed in Qt5, while on the other hand compatibility of the same software with Qt5 has issues that should be fixed, the sooner the better, but without Qt5 at fingertips, it's more difficult to get testing etc. (The sooner Qt5 gets supported, the sooner issues will get fixed.)

In contrast to isolated outdated ports, Qt is one of the core components of a lot of software packages. So relatively important from that point of view. 32 people subscribed to this ticket seems to confirm that.

The high priority doesn't mean that we need it fixed next week. Just that it would be very very welcome if *anyone* could step in and try to contribute something usable. Anything. The ticket has been opened since 2012. A Qt5 PortGroup and a Portfile that starts building Qt and fails with a compiler error would already be helpful.

If you feel that high priority is unjustified, we can lower it again, but I would prefer to get a bit more attention to fixing this; even if you are fully occupied for the next few months, others can help.

[michaelld (Michael Dickens)]

-I- don't have a problem leaving it as High priority, but I doubt that will change how quickly it gets addressed. That said, it's good to have on record the reason(s) for the change -- so, thanks for the quick reply on that question.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I just submitted a first attempt at qt5-mac in r121554 and r121555.
I put myself down as maintainer, but if anyone else has a burning desire to take over, he/she is more than welcome.

If someone wants to try installing, we can close this ticket and start opening brand new ones about how qt5-mac doesn't work.

[mkae (Marko Käning)]

THIS IS AWESOME!!! Thanks for getting this to work, guys!

What about coinstallability with qt4-mac as suggested further up? Are you still considering this?

[macports@…]

Replying to mk@…:

What about coinstallability with qt4-mac as suggested further up? Are you still considering this?

I suspect supporting co-installation would require a modification of qt4-mac, at least as far as the installation of header files.

Currently from qt4-mac you get headers installed to /opt/local/include without a qt4-mac-specific subfolder (e.g. /opt/local/include/QtCore/qobject.h).

I haven't checked out the qt5-mac port yet but even if it installs headers elsewhere, you would have great difficulty including Qt5 headers if you have /opt/local/include in your include path. e.g. #include <QtCore/qobject.h> will happily find the file listed above instead of wherever the Qt5 version of QtCore is installed.

I say this having tried to have both Qt5 installed (from the downloadable package) and Qt4 (from macports) active at the same time, but building against Qt5 proved difficult with /opt/local/include in the include search path.

A solution might be to ensure both versions are in their own subfolder in /opt/local/include:

• /opt/local/include/qt4-mac/QtCore/qobject.h
• /opt/local/include/qt5-mac/QtCore/qobject.h

(actually if the qt5-mac port is like the pre-built downloadable version there'll be frameworks etc, but qt4-mac would still need to move its headers).

Not sure if this applies to any other Qt4/Qt5 files that would otherwise conflict or risk ambiguity in automatic discovery (e.g. I think frameworks/libs & cmake configs probably all have Qt5 in the name to avoid collision).

[michaelld (Michael Dickens)]

Thanks, mcalhoun, for getting this port in place! I haven't tried it yet, but I'll get there sooner or later.

As for co-installability with qt4-mac: I'd suggest changing the qt_dir to "${prefix}/libexec/${name}". That way there's no overlapping in any way, nor is there any default Qt -- we have to point the project at the specific version to find it. In my initial testing while I was playing with installing qt5-mac in parts, this is what I was doing and it seemed to work well. OTOH, there might be enough backward compatibility with Qt4 such that we don't have to do a co-install. I haven't tested the Qt4/5 compatibility to know.

[michaelld (Michael Dickens)]

I'm closing this ticket as "fixed" since it is. If folks have issues with the new qt5-mac port, please open new tickets. This includes suggestions for co-installation.

[mojca (Mojca Miklavec)]

Many many many thanks. I created the ticket #44193 with the request for side-by-side installation.

[mkae (Marko Käning)]

I've built this successfully on 10.9.3!

THANKS, mcalhoun!!!!!

:-)

[hsivank@…]

Successfully build on 10.7.5 !

[mojca (Mojca Miklavec)]

Before opening a new ticket I just wanted to ask whether -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk on 10.7 is expected.

[michaelld (Michael Dickens)]

Mojca: No, not expected. Generally we try to keep the SDK the same as the build OS for any build (not just Qt). I'd say to open a new ticket (if one does not already exist).

[mojca (Mojca Miklavec)]

OK, done: #44203. I'll add more debug output later, but it might be even present on the buildbot.

I also renamed the port name (to the value where I expected to find this old/closed ticket). But that also reminded me: why do we call the port qt5-mac as opposed to just qt5? Is qt5-x11 or something like that planned?

[michaelld (Michael Dickens)]

qt5-mac uses the Quartz/Aqua interface. qt5-x11 would use X11 if we could ever get it to work; qt4-x11 we never got working, though I did put in a good effort. If we wanted to name it just qt5 that would probably be fine, since it's unlikely that anyone will get any other interface working with it on OSX.

[hmeine (Hans Meine)]

Cc Me!