[MacPorts] #37331: qt5-mac

[MacPorts]

#37331: qt5-mac
-----------------------------+--------------------------------
  Reporter:  eric.c.brown@…  |      Owner:  macports-tickets@…
      Type:  request         |     Status:  new
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:
Resolution:                  |   Keywords:
      Port:  qt5             |
-----------------------------+--------------------------------

Comment (by mojca@…):

 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/37331#comment:62>
MacPorts <http://www.macports.org/>
Ports system for OS X