[MacPorts] #51619: qt5.depends_component procedure

[MacPorts]

#51619: qt5.depends_component procedure
---------------------------+----------------------
  Reporter:  RJVB          |      Owner:  mkae
      Type:  enhancement   |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  qt5, qt5-kde  |
---------------------------+----------------------

Comment (by RJVB):

 So... comments on the 2nd proposal, I have some idle time but offline and
 only the diff open in a web browser. More idle time than I thought, so
 this has become another exhaustive message.

 General reaction: this really looks more complicated than necessary, and
 something that I myself would not like to have to maintain.
 It also makes my previous idea of going for just 2 Qt5 PGs each of which
 jumps to the other when necessary much more appealing. It will leave us
 both with much more freedom to do things the way we consider best, hardly
 any common code to maintain but just a generic principle of not breaking
 the other port's functionality. I've already aligned qt5-kde to a few
 important choices that I would have preferred doing without (separate
 component subports for instance), I think I could make a few "strong
 suggestions" how to implement the qt5/qt5-kde co-habitation :) Esp. since
 I've been studying the question for about a year now (and I am the one
 without commit access to repair things quickly when required).

 I think we should concentrate now on providing a qt5.depends_component
 function that works for port:qt5 (qt55 etc), and rectify things later as
 things become clearer. port:qt5-kde will still have to go through whatever
 review process is waiting for it. The main importance is that ports can
 begin to declare depspecs in a future-compliant manner.

 That means there's quite a bit of code in the proposal that concerns a
 port that doesn't exist yet, and which may have to be changed later on. Or
 simply removed because never used (for instance because the corresponding
 case will always be handled in qt5-kde-1.0.tcl).

 Another general remark: let's not assume too hard yet that a port:qt56
 will become *necessary*. There will never be a qt56-kde for instance if
 enough KF5 projects drop support for Qt 5.6 .

 More specific points:
 - Let's use a simple, short and all-lowercase namespace. I'm not convinced
 that there's any need to have a namespace for things supposed to be used
 only inside the PG files (which is what Qt5PortGroup suggests). Evidently
 this critique is moot if the namespace isn't intended to be used in
 dependent ports (and I can thus use my own).
 My own approach with namespaces and PGs is this: anything "private" that's
 not supposed to be used by ports (the ones depending on Qt5, excluding
 port:qt5* and port:qt5-kde) is put inside a real namespace, anything
 that's intended for use by ports in a "fake" namespace. That would give
 `qt5::something_private` and `qt5.depends_component`.

 - I'm not at all convinced either that the check for the installed Qt5
 version/flavour has to be done in the pre-configure. I cannot judge for
 port:qt5 vs qt55 vs qt5x but detecting qt5x vs. qt5-kde doesn't even
 require to query the registry. Simple file existence checks can tell those
 ports apart, and that will always be faster than querying the registry.
 Rule of thumb: this kind of code is evaluated in dependency calculations,
 which can already take a lot of time for highlevel ports with lots of
 dependencies. As maintainers we're the first concerned by that aspect.

 - what does port::register_callback do?
 In general I think that the approach with a function that is called in
 addition to `qt5.depends_component` is maybe very elegant and all, but it
 looks like overkill. In the end you're using a lookup table run in
 interpreted code, which takes about just as much space as writing a hard-
 wired table like for the checksums. With a table there's no need to write
 a function that registers the entries and its pretty certain that Tcl code
 that just defines and sets an internal variable type executes much more
 efficiently than a user-written procedure. I think you're using
 `qt5_private_components` as a sort of cache to make `register_dependents`
 a bit more efficient, but I wonder if that isn't more complexity with
 little benefit (other than keeping the maintainer's neurones in shape each
 time maintenance is required :) ).

 - I like my `qt5.using_kde` variable better than `qt5.kde_variant`, and a
 few ports are already using `qt5.using_kde`. The latter would be
 appropriate as a shortcut for `port:qt5 +kde` while the former is a
 shortcut for "we're using qt5-kde". I don't think there's any point in
 making it an "option" either (i.e. a procedure in disguise) because it
 only has 2 sensible values. Again, efficiency and simplicity.

 - `proc qt5.depends_component {first args} {}`
 AFAIK this will require 2 arguments at least; the short way to write a
 procedure to that requires at least a single arguments is `proc
 qt5.depends_component {first {args 1}}` (i.e. set a special default value
 for the 2nd argument).

 I hope that's about all...

--
Ticket URL: <https://trac.macports.org/ticket/51619#comment:31>
MacPorts <https://www.macports.org/>
Ports system for macOS