[MacPorts] #42073: p5-wx does not build

[MacPorts]

#42073: p5-wx does not build
--------------------------------+--------------------------------
  Reporter:  macsforever2000@…  |      Owner:  macports-tickets@…
      Type:  defect             |     Status:  new
  Priority:  Normal             |  Milestone:
 Component:  ports              |    Version:
Resolution:                     |   Keywords:
      Port:  p5-wx              |
--------------------------------+--------------------------------

Comment (by mojca@…):

 There are a few things that I don't understand:
   * What exactly is the difference and connection between `p5-alien-
 wxwidgets` and `p5-wx`?
   * Which one works with wxWidgets 2.9 and which one doesn't? (Which
 combinations did you test when you created the port?)
   * How is it possible that the server contains a binary package for
 `p5.16-wx` if the package fails to build now? Did the build happen to work
 with wxWidgets 2.9.5 and now only fails with 3.0.0?
   * Where do all the compiled files end up? The only binary file I notice
 seems to be the following (but I may be missing some files) and it doesn't
 link to wxWidgets:
 {{{
 > otool -L  /opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-
 2level/auto/Wx/wxPerl.app/Contents/MacOS/wxPerl
 /opt/local/lib/perl5/vendor_perl/5.16.1/darwin-thread-multi-
 2level/auto/Wx/wxPerl.app/Contents/MacOS/wxPerl:
         /opt/local/lib/perl5/5.16.1/darwin-thread-multi-
 2level/CORE/libperl.dylib (compatibility version 5.16.0, current version
 5.16.1)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 159.1.0)
         /usr/lib/libutil.dylib (compatibility version 1.0.0, current
 version 1.0.0)
 }}}

 Just for explanation: when B depends on A and C depends on B, direct
 dependency between C and A is "polite to have" in cases when upgrading A
 requires a revbump of C or something similar to that. The main question
 is: does this package need a revbump when wxWidgets is upgraded or not?
 Seeing that it uses wxWidgets sources I would guess so, but I'm unable to
 figure out the details and how this works. Most dependencies of `py-
 wxpython-x.y` don't need a revbump when `wxWidgets` gets upgraded because
 they are pure python scripts. Some dependencies however compile C(++) code
 and the resulting binary or library is linked against `wxWidgets`
 libraries (not that this is properly indicated, but well ...)

 Usually a package would link against
 `/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_baseu-2.9.dylib`
 and then the link would be broken when wxWidgets gets upgraded. I don't
 know if this is also the case here. I'm unable to figure out why C code
 gets compiled and where it ends up.

 As far as compatibility with wxWidgets 3.0 is concerned: how is it
 possible that nobody noticed the incompatibility since April? It is true
 that I probably didn't test the GUI when compiling the ports in August
 2013 (I had enough problems convincing `p5-alien-wxwidgets` to compile at
 all), but I would expect the port to fail already when you first created
 it if there is some major incompatibility.

 In case of a minor incompatibility you would probably be better off if you
 try to fix the remaining glitches and/or request from the upstream to fix
 those.

 If you are thinking about switching to version 2.8 (which is something
 that I would really like to discourage you from doing), you'll have to
 deal with the following facts:
   * You either need to offer an option to switch between 2.8 and 3.0 (in
 case that any ports do work with 3.0) or provide just support for 2.8.
   * If you offer support for both, you'll end up with a bit of a mess: you
 will need two separate ports which will most probably conflict with each
 other (in Python one can only use, say Python 2.6 + wxWidgets 2.8 and
 Python 2.7 + wxWidgets 3.0; one cannot use Python 2.7 with both at the
 same time).
   * Version 2.8 works for 64-bit, but only via the ugly `gtk` (`x11`).
   * (I would like to declare wxWidgets 2.8 obsolete one day and remove it.
 I'm not sure if this is feasible, but if p5-wx won't stand in the way,
 that will be a bonus.)

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