[MacPorts] #38375: Ports depending on wxWidgets* should either use path-style dependencies or variants instead

[MacPorts]

#38375: Ports depending on wxWidgets* should either use path-style dependencies or
variants instead
-------------------------------------------------+-------------------------
  Reporter:  egall@…                             |      Owner:  macports-
      Type:  defect                              |  tickets@…
  Priority:  Normal                              |     Status:  new
 Component:  ports                               |  Milestone:
Resolution:                                      |    Version:  2.1.3
      Port:  codeblocks FileZilla fityk hugin-   |   Keywords:
  app lisaem py-wxpython rt-volume-rendering     |
  usbprog wxd otrproxy                           |
-------------------------------------------------+-------------------------

Comment (by egall@…):

 Replying to [comment:8 mojca@…]:
 > 1. The majority of this mess is there just because wxWidgets 2.8 and 2.9
 are not allowed to coexist. Many ports like gnuplot could simply default
 to 2.9, but they cannot because the port cannot demand using by default a
 package (wxWidgets 2.9) that conflicts with dependencies of another
 package, say codeblocks (which depends on 2.8). If versions 2.8 and 2.9
 could coexist, life would be *a lot* easier. See my ticket #39807. My
 belief is that once a clear separation is done and conflict is removed, it
 will become a lot easier for port maintainers to add proper variants (and
 to implement variants properly). Let's solve that issue first.
 >

 Agreed, making them not conflict would be a good idea.

 >
 > 2. I believe that we need a way to quickly find all ports that depend on
 any wxWidgets version. This is particularly important when doing major
 changes on wxWidgets naming scheme, when introducing and testing new
 versions of wxWidgets (for example when version 3.0 will be out), when
 doing revbumps, ... What do you think of adding {{{PortGroup wxWidgets
 1.0}}} to every such port, even if the group doesn't do anything useful
 yet?
 >

 The group would have to actually ''exist'' first though, wouldn't it?
 Regardless of whether it actually does anything useful yet?

 >
 > 3. We need consistent naming scheme for wx variants and consistent
 behaviour across the ports, taking into account that:
 >   a. There are ports that require wxWidgets and there are ports where
 wxWidgets are simply optional (gnuplot).
 >   b. There are ports that only work with one version, but not the other
 (only 2.8, only 2.9) and those that work with both. Also some that work
 with wxgtk (on freebsd).
 >   c. In most cases it probably isn't relevant which wxWidgets the port
 depends on, but in some cases it might be desirable to support both, at
 least for testing purposes.
 >   d. While we could probably focus on 2.9/3.0 now and only depend on 2.8
 for ports that don't work with 2.9, we need to be prepared for the arrival
 of 3.2 with the naming scheme & naming strategy. Maybe even for 3.0-devel
 and alike ;)
 >   d. Version 2.8 doesn't work on 10.8(?) and doesn't allow building
 64-bit binaries. Version 2.9/3.0 requires at least 10.5 (but probably 10.4
 is not really supported any more?).
 >   e. Some ports already do some more or less advanced magic to use the
 "right" version of wxWidgets and special care is needed to "translate"
 those options properly.

 Gah, that's confusing...

 >
 > 4. We need to write some guidelines for maintainers of ports which
 depend on wxWidgets. This is not a priority, but I believe that it needs
 to be done at some point.
 >

 Implementing the naming scheme mentioned above would require some sort of
 guidelines to make sure that people follow the naming scheme.

 >
 > 5. The path-style dependencies shouldn't be used because wxWidgets 2.8
 and 2.9 are incompatible with each other (path-style can be used with
 released and development version that are closely related).
 >

 OK, I was just throwing ideas out there...

 >
 > 6. In my opinion this transition needs to happen before the official 3.0
 release, to leave enough time for bugfixing and reporting bugs upstream.
 >

 When is that supposed to be done?

 >
 > 7. I wouldn't force changing ports until (1) is done and (3) is clear
 /well-defined.
 >

 What do you mean by "force" here?

 >
 > I don't know if the following is a good idea, but something non-
 intrusive like the following could be put into each port that depends on
 wxWidgets just to mark where the work needs to be done:
 > {{{
 > PortGroup wxWidgets 1.0
 >
 > # which versions of wxWidgets are supported
 > # add comments whether it's known (not) to work or just hasn't been
 implemented/tested yet
 > wxwidgets.version  28 30
 > # or wxwidgets.compatibility
 >
 > # for ports like gnuplot
 > wxwidgets.optional  yes
 > }}}
 >

 Go for it. Actually write the PortGroup first though.

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