[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 ryandesign@…):

 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.

 Correct. This should be fixed.

 > 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?

 Why? You can use `grep` to identify those ports already.

 > 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.

 I've gone through all this before on the list. My opinion is that there
 should be wxWidgets28, wxWidgets30, wxWidgets32 ports. There should be no
 -devel ports. The ports should not conflict with one another. There should
 be no wx* variants; ports that need wx should depend on the latest
 supported stable version and be done with it. Maintainers who wish to test
 whether newer versions would work can edit their portfile locally.
 Currently, ports should depend on wxWidgets30 if compatible, even though
 it is not yet stable, because as you said 2.8 doesn't work with current OS
 X.

 As for Tiger, it's unfortunate that the wx developers have dropped 10.4
 support, but that's their choice to make. 10.4 support in MacPorts is
 dwindling. Maintainers may support it if desired, but don't have to. I
 wouldn't have a problem with wx ports not supporting Tiger anymore.

 > 5. The path-style dependencies shouldn't be used because wxWidgets 2.8
 and 2.9 are incompatible with each other

 And unnecessary because once (1) is fixed there will be only a single wx
 port providing any given file.

 > (path-style can be used with released and development version that are
 closely related).

 Should not occur.

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