[MacPorts] #52922: qt5 @5.6.2_0: build errors on 10.7
MacPorts
noreply at macports.org
Sun Nov 20 23:01:47 CET 2016
#52922: qt5 @5.6.2_0: build errors on 10.7
-------------------------------------------------+-------------------------
Reporter: mojca | Owner:
| MarcusCalhoun-Lopez
Type: defect | Status: accepted
Priority: Low | Milestone:
Component: ports | Version:
Resolution: | Keywords: lion
Port: qt5 qt5-qtdoc qt5-qtmultimedia |
qt5-qtserialbus qt5-qtwebengine qt5 |
-qtwebengine-docs qt5-qtwebkit qt5-qtwebkit- |
docs qt5-qtwebview qt5-qtwebview-docs |
-------------------------------------------------+-------------------------
Comment (by RJVB):
Replying to [comment:6 MarcusCalhoun-Lopez]:
> As soon as qt5 is upgraded not 5.7, I also planned on creating a qt56
port as it is has [https://blog.qt.io/blog/2015/12/18/introducing-long-
term-support/ long term support].[[BR]]
This has already been discussed on Trac or the ML; the consensus was that
maintaining support for 5.6 only makes sense if newer Qt versions drop
support for OS X versions that we'd like to continue to support. But if
10.8 support is dropped only in Qt 5.8, why would we maintain a Qt 5.6
port if we could just as well maintain 5.7 as our own LTS version?
I would personally prefer to maintain platform-specific maximum versions
in a single Portfile as much as possible, but that is less cumbersome for
me since qt5-kde uses only 3 distfiles at the moment.
> If it was a bad idea, others [https://github.com/Homebrew/homebrew-
versions/pull/1191 have made the same mistake], so at least we are in good
company.
I'm not sure if HB is good company in this aspect :)
> I would suggest the following solution: in {{{qt5-1.0.tcl}}},
> In Portfiles, replace dependency {{{port:qt5-qtbase}}} with
{{{path:lib/pkgconfig/Qt5Core.pc:${qt_name}-qtbase}}}.[[BR]]
> This would be fairly minimal change that would also allow us to finally
commit qt5-kde since it is a drop-in replacement.[[BR]]
> I have a script that makes the changes to Portfiles.
That's comparable to but considerably more complicated and less readable
than my solution. We may end up with something similar, but we're not
there yet.
With my proposal, Portfiles can just use expressions like
{{{
qt5.depends_components qtsvg qtdeclarative qttools qtwebkit
}}}
to declare dependencies on anything that is not added automatically by the
actual PortGroup. If port:qt5-kde (or port:qt5-kde-devel, in my or Marko's
case) is used this translates to
{{{
depends_lib-append
path:libexec/qt5/Library/Frameworks/QtCore.framework/QtCore:qt5-kde \
path:libexec/qt5/Library/Frameworks/QtWebKit.framework/QtWebKit:qt5
-kde-qtwebkit
}}}
because only QtWebKit has its own real subport (there's no point in
installing stubs ports if it can be avoided).
otherwise it translates to
{{{
depends_lib-append path:lib/pkgconfig/Qt5Core.pc:qt5-qtbase \
port:qt5-qtsvg \
port:qt5-qtdeclarative \
port:qt5-qttools \
port:qt5-qtwebkit
}}}
(or idem with qt55 instead of qt5 on 10.7)
Port:qt5-kde indeed installs the .pc files in the same location as
port:qt5, but it would not be wise as a general rule to allow ports to mix
and match Qt components from port:qt5-kde and port:qt5. Path-style
dependencies work great, but they only allow the user to install an
alternative port explicitly. If the requested dependency is not already
provided, it is still the port specified after the colon that will be
installed, and that shouldn't be `port:qt5-foo` instead of `port:qt5-kde-
foo` or vice versa.
> > It might have been more useful to investigate whether C++11 support is
sufficient in GCC 4.7+ to build at least QtWebKit on 10.7.
> You seem to have made progress in building Qt with MacPorts compilers,
but to me, Qt seems very intent on using OS compilers.[[BR]]
> With such a large piece of software as Qt, I would prefer to stay as
close to the supported configuration as possible.
Actually, I think they only do that because they consider that it's the
only compiler that people have available, and at some point there must
have been a reason not to rely on the clang proxies installed in /usr/bin.
Do you have explicit statements of the contrary?
> Please correct me if I am wrong, but isn't QtWebEngine already a subport
in both qt5 and qt5-kde?[[BR]]
> Are you suggesting that we create a new Portfile?[[BR]]
Yes, it is. It does however not contain anything specific to KDE, but it
will very likely drop support for older OS X versions quicker than the
rest of Qt, meaning an additional OS/Qt version aspect to manage.
> Is my proposed solution above sufficiently easy for Portfile maintainers
to use?[[BR]]
Not really IMHO. To summarise:
- maintainers will have to specify the path:-style dependencies explicitly
- the installed "flavour" would have to be made available in `qt_name` to
avoid all (future) possibility for untested mix-and-match
> It seems to fit in with standard MacPort practices.
Yes, and evidently the wrapper I add on top of it just hides the more
cumbersome aspects of those practices.
I have implemented a similar wrapper to specify dependencies on KF5
frameworks (there are 60+ of those...) and it makes it both much easier to
specify a list of dependencies and to read the resulting Portfiles. All
you have to deal with are names of components (frameworks), no need to
bother with prefixes and names of the files that indicate whether they're
installed or not.
In any case, we must come to an agreement on solving the PortGroup hurdle
via a header PortGroup that includes the actual PortGroup (and includes
some shared stuff).
If that solution is retained, I'd propose myself as the principal
maintainer of that header PortGroup (which doesn't and won't change
anything in the way port:qt5 works). It seems only fair that I'd bear the
brunt of the extra work, and I have been able to be more reactive in
addressing issues in the recent past.
--
Ticket URL: <https://trac.macports.org/ticket/52922#comment:7>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list