#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by michaelld@…): There are some good suggestions in your last comment, René. * When we get QtChooser and/or qt*-kde implemented, we'll need some of these in place; until then, I think we can leave them alone. * Moving sqlite3 back to the main qt4-mac makes sense too, because otherwise Assistant fails to execute; either that or moving Assistant to a separate port that depends on the sqlite3 plugin; much easier to do the former. * I don't know enough about "-no-exceptions" to comment. Can you provide a link that shows that this is the default for Qt-provided binaries? I'm happy to go that way with a variant if it's the usual. At least on Qt4, when I do "./configure --help" I see that "-exceptions" is the default; that's why it is enabled by default. * No matter the proper way to do a parallel build, MP's way works, yes? If so, I'll leave that as is. * I think setting "qt_name qt4" is fine. Reads nicely in directory listings too. That's what I use for my internal testing, too. * my worry about moving data, plugins, and other stuff into ${prefix}/share/qt4 is if/when there is qt4-kde or qt4-x11 that provides its own versions of these. A well-written project will use the specified QMAKE to glean the location of these, so they really don't matter. Hence, I'm inclined to leave them inside the libexec/qt4 area. I'll look over this list one last time tonight & also review any other comments. Might be tomorrow for the actual checkin, but I'll try for tonight. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:68> MacPorts <https://www.macports.org/> Ports system for OS X