Opened 8 years ago
Last modified 2 years ago
#53778 new submission
Qt5/qt5-kde PortGroup
Reported by: | RJVB (René Bertin) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | haspatch, portgroup | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), mkae (Marko Käning), mojca (Mojca Miklavec) |
Port: | qt5 |
Description
We should be picking up this affair, and I think the proper way to proceed is to tackle the PortGroup question first, and the main goal of this ticket is to apply suitable changes to the PortGroup files for the current port:qt5 port family.
That means adding a hopefully simple section (to qt5-1.0.tcl and qmake5-1.0.tcl) that will take care of *transferring* control to the appropriate PortGroup (qt5-kde-1.0.tcl or qmake5-kde-1.0.tcl respectively). That section will probably also contain a bit of "glue" because of variables or procedure missing (or gone missing) from qt5-1.0.tcl .
One important note and big request: addres https://trac.macports.org/ticket/53777
I am still working on the qt5-kde-1.0 vs. qt5-1.0 inclusion logic so for now I only attach the qmake5*-1.0 PortGroups which are in a state that should work with the existing other PortGroup files. The change to qmake-1.0.tcl assumes that the PortGroup qt5 1.0
statement will include the proper Qt5 PortGroup, and transfers control to qmake5-kde-1.0.tcl if port:qt5-kde is being used (is installed). This is detected by checking qt5.using_kde
(following that variable's intended use).
KDE software rarely if ever uses QMake, so there is no justification for software that does to impose the use of port:qt5-kde so the qmake5-kde PortGroup cannot be included directly. There are some KDE dependencies that use QMake however; ports for those could do this to indicate their preference for port:qt5-kde :
set qt5.prefer_kde yes PortGroup qmake5 1.0
Attachments (4)
Change History (9)
Changed 8 years ago by RJVB (René Bertin)
Attachment: | qmake5-1.0.diff added |
---|
Changed 8 years ago by RJVB (René Bertin)
Attachment: | qmake5-kde-1.0.tcl added |
---|
comment:1 Changed 8 years ago by RJVB (René Bertin)
FWIW, I thought I had made this an "enhancement" ticket, but "submission" is probably appropriate too.
Changed 8 years ago by RJVB (René Bertin)
Attachment: | qt5-1.0-for-kde.diff added |
---|
patch for qt5-1.0.tcl
comment:2 Changed 8 years ago by RJVB (René Bertin)
I have now a working prototype for the changes I would make to the qt5 1.0 PG. In order:
- Move the
qt5.using_kde
declaration downwards, until *after* the potential control transfer to qt5-kde-1.0.tcl . This means the qt5-kde PG can continue to assumeqt5.using_kde
is never defined when it is loaded for the 1st time (and also means it can continue to use a standard Tcl variable). I realise it means that the variable won't be set whenjust_want_qt5_version_info
is true, but I think there is little need for that anyway (correct me if I'm wrong). - the control transfer logic itself, with what I hope are sufficient comments to explain what it does and why. In particular I think it's easier to distinguish between active
port:qt5-qtbase
andport:qt5-kde
variants from installed files rather than from the registry for 2 reasons:- there are now 3 qt5-qtbase ports ({qt5,qt55,qt56}-qtbase) with possibly more to come
- qt5-kde may also have a matching qt56-kde port, and also has a qt5-kde-devel variant that may be committed as well as another devel variant that will remain private to KF5 port maintainers and testers.
All those different Qt5 ports install the same files, with certain differences between qt5*-qtbase and qt5*-kde* that are independent of Qt version; the depspecs provided by qt5.depends_component
are based on this fact too.
(And as argued a while back on the ML: a single check for the existence of a given file *must* require less operations than doing a pattern-match on the result of a registry lookup, and is thus almost certainly faster at least in theory.)
You may notice the references to OS X 10.6 . Port:qt5-kde contains the rather blackish magic I concocted quite a while ago now to build Qt 5.3.2 on that legacy OS version. It worked fine (even a universal build, IIRC) but I haven't tested it in a long time. In itself this support has nothing to do with KDE (much of KF5 now requires more recent Qt versions anyway) so I'm open to discussion about separating it, for instance in favour of a port:qt53 .
comment:3 Changed 8 years ago by RJVB (René Bertin)
Here's the equivalent block from my own qt5-kde-1.0.tcl
PG, transferring control to qt5-1.0.tcl
in the opposite cases and when just_want_qt5_version_info
is true.
I've paid a bit less attention to comments and layout here.
if {[tbool just_want_qt5_version_info]} { PortGroup qt5 1.0 return } # Check what Qt5 installation flavour already exists, or if not if the port calling us # indicated a preference. If not, use the default/mainstream port:qt5 . # Also use qt5-kde if we're on 10.6 because qt5-kde provides a fallback to Qt 5.3.2 on that OS version # first, check if port:qt5-kde or a port:qt5-kde-devel is installed, or if we're on Mac OS X 10.6 # NB: the qt5-kde-devel ports may never exist officially in MacPorts but is used locally by KF5 port maintainers! if {[file exists ${prefix}/include/qt5/QtCore/QtCore] || ${os.major} == 10} { # Qt5 has been installed through port:qt5-kde or port:qt5-kde-devel ui_debug "Qt5 is provided by port:qt5-kde" # we're in the right PortGroup, otherwise we'd need to # PortGroup qt5-kde 1.0 set qt5.using_kde yes } elseif {[file exists ${prefix}/libexec/qt5/plugins] && [file type ${prefix}/libexec/qt5/plugins] eq "directory"} { # qt5-qtbase is installed: Qt5 has been installed through a standard port:qt5 port # (checking if "plugins" is a directory is probably redundant) ui_debug "Qt5 is provided by port:qt5" PortGroup qt5 1.0 if {[info exists qt5.prefer_kde] && [info exists building_qt5]} { # user tries to install say qt5-kde-qtwebkit against qt5-qtbase etc. ui_error "You cannot install a Qt5-KDE port with port:qt5 or one of its subports installed!" # print the error but only raise it when attempting to fetch or configure the port. pre-fetch { return -code error "Deactivate the conflicting port:qt5 port(s) first!" } pre-configure { return -code error "Deactivate the conflicting port:qt5 port(s) first!" } } # we're done return } elseif {[info exists qt5.prefer_kde]} { # The calling port has indicated a preference and no Qt5 port is installed already ui_debug "Qt5 will be provided by port:qt5-kde, by request" # we're in the right PortGroup, otherwise we'd need to # PortGroup qt5-kde 1.0 set qt5.using_kde yes } else { # default fall-back to mainstream port:qt5 ui_debug "Qt5 will be provided by port:qt5 (default)" PortGroup qt5 1.0 # we're done return } # # this shouldn't be necessary (and impossible if we return immediately after loading qt5-1.0.tcl): # if {![tbool qt5.using_kde]} { # # we're back from `PortGroup qt5 1.0`, add some finishing touches and then return # if {[info exists qt5.prefer_kde]} { # # this is a port that prefers port:qt5-kde and thus expects most of Qt5 to be installed # # through that single port rather than enumerate all components it depends on. # depends_lib-append port:qt5 # } # if {![info exists qt_cmake_defines]} { # # the Qt5 PortGroups used to define a variable that is no longer provided by qt5-mac-1.0.tcl; # # set it to an empty value so that it can be referenced without side-effects. # global qt_cmake_defines # set qt_cmake_defines "" # } # # we're done now. # return # } ######### checks that should never trigger (and raise errors) #########
Changed 8 years ago by RJVB (René Bertin)
Attachment: | qt5-1.0-for-kde.2.diff added |
---|
updated qt5-1.0 PG patch (for rev. 9e44fe58a605e66730f8f50353334984318a42ea)
comment:5 Changed 2 years ago by mascguy (Christopher Nielsen)
Keywords: | portgroup added |
---|
Add keyword portgroup, to pg-related tickets
for reference, the qmake5-kde-1.0.tcl version