[MacPorts] #24350: proposed new Portfiles for wxWidgets and wxPython

[MacPorts]

#24350: proposed new Portfiles for wxWidgets and wxPython
-------------------------------+--------------------------------------------
 Reporter:  jjstickel@…        |       Owner:  macports-tickets@…                   
     Type:  enhancement        |      Status:  new                                  
 Priority:  Normal             |   Milestone:                                       
Component:  ports              |     Version:  1.8.2                                
 Keywords:                     |        Port:  wxWidgets-python py26-wxpython       
-------------------------------+--------------------------------------------

Comment(by jjstickel@…):

 Replying to [comment:21 macsforever2000@…]:
 > This is confusing to me as well. Maybe you are right.
 >
 It is indeed confusing.  I tried to make a detailed explanation in my long
 comment above.

 > The only problem with that is that a port cannot depend on a variant.
 See ticket:126.
 >

 Yes, this is a problem.  In other ports I see a workaround where a build
 message instructs the user to install dependent ports with a specific
 variant.  I hate to see different ports of the same program just to
 support variant dependencies.

 >
 > Why didn't we just update the existing wxwidgets port to 2.8.10.1
 instead of adding the wxwidgets-python port again?

 See ticket #23797 and my explanation above.

 > So perhaps this could all be cleaned up by making a new wxwidgets-gtk
 port that has wxwidgets (updated to the latest version) as a dependency.
 We remove the +gtk variant from wxwidgets. Then we remove the wxwidgets-
 python port and the wxgtk port. py26-wxpython retains the +gtk variant and
 depends on wxwidgets-gtk in that case. xchm depends on the new wxwidgets-
 gtk port now too and avoids the variant issue. Can you make the proposed
 wxwidgets-gtk port? I'm not sure I have the time (or knowledge) to do it
 myself.

 Since I see using the gtk toolkit as a temporary solution, I still suggest
 sticking to the +gtk variant as a workaround for wxpython.  For xchm,
 maybe we can just leave wxgtk as it is.

-- 
Ticket URL: <http://trac.macports.org/ticket/24350#comment:23>
MacPorts <http://www.macports.org/>
Ports system for Mac OS