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

 I'll try to answer the best I can. I am very ignorant of both perl and wx.

 Replying to [comment:4 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`?

 I believe p5-alien-wxwidgets alters wxWidgets in some way so as to make it
 compatible with perl-wx. Beyond that, I don't know how or why.

 >   * Which one works with wxWidgets 2.9 and which one doesn't? (Which
 combinations did you test when you created the port?)

 Honestly, I don't remember. These ports may never have worked. I need
 p5-wx, however, because it is a dependency for
 [http://bruceravel.github.io/demeter/ Demeter], which I'm trying to port
 to MacPorts.

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

 It did use to build in the past and so you are right, it probably built
 with 2.9.5 and it keeps the binary because the version has not been
 updated.

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

 I don't remember and I cannot build it anymore now.

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

 I don't really know anything about p5-wx. But I think that is safe to
 assume. So we should probably depend on wxWidgets-3.0 directly.

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

 I don't know. I have asked on the mailing list for perl-wx twice and
 gotten no response.

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

 I don't want to - or have any plans to - use wxWidgets 2.8. I want to move
 forward with 3.0. I filed this ticket because I am stuck and don't know
 how to proceed.

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