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

 Here are some of my thoughts:

 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.

 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?

 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.

 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.

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

 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.

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

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

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