Hi,
You may be aware that Qt have designated v5.6 a long-term support version that
will be maintained in parallel to 5.7 (already released) and (probably) beyond.
I still have to look at the exact implications, but this could well put us in a
situation where we will need to provide a 5.6 port and a current/latest release
version port. In any event it will be necessary to provide a Qt5 port that
follows the current/latest release, because that's probably where the real
evolution will take place. Qt are usually pretty good at maintaining backward
compatibility (even at the ABI level) so it may not be absolutely required to
keep a 5.6 release port around, except possibly to ensure compatibility with
earlier OS X versions, but again, I have to look into this.
Anyway, how should we approach this? The Qt portfiles are already pretty
complicated, the one for port:qt5 probably even more so than mine for
port:qt5-kde. However, my port file and directory have already been set up to
support multiple versions.
So if we're going to support Qt 5.6LTS and Qt 5.7+, it would be most logical
for me to implement this via a +LTS variant. Basically that variant would
- setting a 5.6.x version plus the corresponding checksums (maclhoun's port:qt5
would probably want to put its checksum tables into version-specific files,
like I do for the KF5 frameworks)
- maintain an LTS subdir in ${filespath}, for those patches that are different
between 5.6.x and 5.7+
The drawback would be that the LTS version will require building from source
for everyone. If that's an unacceptable hurdle we'd probably be looking at a
separate set of ports with their own port dir because I don't really want to
introduce yet more subports to my own port:qt5-kde (and I presume mcalhoun will
be equally enthusiastic about the idea).
Using separate ports in their own port dirs *may* be the approach given the
least maintenance though, if we presume that 5.6 is going to evolve less
(often). Especially since my efforts to make port:qt5-kde and port:qt5 drop-in
alternatives using path:-style dependency declarations in the PortGroup have
already prepared the way for supporting different versions rather than
different build flavours through a single mechanism to declare dependencies on
Qt.
R.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
