#24350 closed enhancement (fixed)
proposed new Portfiles for wxWidgets and wxPython
Reported by: | jjstickel@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.8.2 |
Keywords: | Cc: | michaelld (Michael Dickens), mww@…, jyrkiwahlstedt, jameskyle@…, hmng@…, macports@…, mf2k (Frank Schima), Veence (Vincent), totonixsame@…, cooljeanius (Eric Gallager) | |
Port: | wxWidgets-python py26-wxpython |
Description
I propose a new port "wxWidgets-python" to be the dependency for py*-wxpython with a version number that is in sync with that of the latest stable release of wxPython.
I also add the variant "gtk" for both wxWidgets-python and py26-wxpython. This allows these ports to be built against x11/gtk2 on 64 bit Snow Leopard, avoiding universal builds. This is an effective stop-gap until wx developers release 2.9.x with full Cocoa support.
Portfiles are attached. Further rational and discussion points below.
Attachments (8)
Change History (45)
Changed 15 years ago by jjstickel@…
Changed 15 years ago by jjstickel@…
Attachment: | changeset_r61009.diff added |
---|
patchfile for wxWidgets-python
Changed 15 years ago by jjstickel@…
Attachment: | wxpython28101_gdiwrap.diff added |
---|
patch for py26-wxpython
comment:1 Changed 15 years ago by jjstickel@…
I have come to expect some level of difficulty when using free software, but I am quite amazed by the mess of wxwidgets/wxpython! Anyway, there are 2 primary problems addressed by this ticket: 1) the stable release of wxpython is often out of sync with that of wxwidgets, and 2) current stable wxWidgets and wxPython do not have support for cocoa, but carbon does not build 64 bit. There must be close to a dozen macports tickets related to these problems.
Regarding problem 1, as I state in the ticket description, I propose a new port "wxWidgets-python" to be the dependency for py*-wxpython with a version number that is in sync with that of the latest stable release of wxPython. This wxWidgets version can be installed from the bundled wxPython sources. Those that are primarily interested in using wxPython may be quite satisfied by this solution. Those that want only wxWidgets without python can install the official stand-alone version of wxWidgets. I hope the macports developers are amenable to my proposal. I am open to changing or shortening the name of the port, e.g. "wxWidgets-py".
For problem 2, possible solutions, as I currently understand them, are:
a) build wxwidgets/wxpython against 32 bit carbon; to do so requires all dependencies to be built 32 bit or universal
b) build wxwidgets/wxpython from development sources (svn) with cocoa (see ticket #21530)
c) build wxwidgets/wxpython against gtk +x11 (solution proposed here)
d) build wxwidgets/wxpython against gtk +quartz (not tried)
From my own experience, I ran into all kinds of problems trying a&b. Fortunately, I found solution c (build against x11/gtk) to be quite satisfactory, and that is the solution I provide in the attached portfiles in the form of a "gtk" variant. Solution d may be another option, but I have not tried it myself. Again, I hope the macports developers are amenable to the addition of a gtk variant for wxwidgets and wxpython.
For those interested, please try out the portfiles. There may be bugs or better ways to handle things. For example, I simply removed sdl support from the gtk variant of wxWidgets since it caused a build error, but there may be an easy way to fix this.
comment:3 Changed 15 years ago by mf2k (Frank Schima)
Cc: | mww@… jwa@… jameskyle@… added |
---|---|
Keywords: | wxwidgets wxpython 10.6 Snow Leopard removed |
Port: | wxWidgets-python py26-wxpython added |
Type: | update → enhancement |
comment:6 Changed 15 years ago by willic3@…
I have managed to build py26-mayavi using the portfiles and patches attached to this ticket, along with the py26-mayavi port that prevents checking for Carbon (http://trac.macports.org/ticket/21994). I also built VTK5 with X11, and I end up with a pure X11 version of mayavi2 that seems to work OK.
I'm running OS X 10.6.3 (64-bit mode) on a MacBook Pro.
Please let me know if you need any more info.
comment:9 Changed 14 years ago by mf2k (Frank Schima)
I tried to install this with the +gtk variant but i see the following conflict:
Error: Target org.macports.activate returned: Image error: /opt/local/bin/wx-config is being used by the active wxgtk port.
Can you fix this conflict?
I think we should make +gtk the default variant so it works on Snow Leopard automatically.
comment:10 Changed 14 years ago by mf2k (Frank Schima)
Cc: | vince@… added |
---|
comment:11 Changed 14 years ago by mf2k (Frank Schima)
I added wxWidgets-python in r67813. Note that in the previous comment about the conflict with wxgtk, I was talking about the wxWidgets-python portfile you submitted.
comment:12 Changed 14 years ago by mf2k (Frank Schima)
I updated py26-wxpython in r67814. This works for me on Snow Leopard. Thanks!
I'm leaving this ticket open until the conflict between wxWidgets-python +gtk and wxgtk is resolved.
comment:13 Changed 14 years ago by jjstickel@…
What is an acceptable fix for the conflict? My solution would be to add "conflicts" lines to both wxWidgets-python and wxgtk since they both provide wxwidgets anyway (just different versions). If this is OK, I can provide patches. If you want to allow them to coexist, then that is probably beyond my ability.
Thanks, Jonathan
comment:14 Changed 14 years ago by jjstickel@…
Another thought: wxgtk and current wxWidgets ports are essentially different variants of the same program. Therefore, I think wxgtk should be removed and a gtk variant be added to wxWidgets, analogous to my contributed wxWidgets-python port here. Then wxWidgets and wxWidgets-python would simply conflict with each other.
comment:15 Changed 14 years ago by mf2k (Frank Schima)
comment:16 Changed 14 years ago by mf2k (Frank Schima)
See #24946 for my proposed change to the xchm portfile.
comment:17 follow-up: 18 Changed 14 years ago by mf2k (Frank Schima)
Can you modify wxWidget-python to include use wxgtk instead?
comment:18 Changed 14 years ago by jjstickel@…
Replying to macsforever2000@…:
Can you modify wxWidget-python to include use wxgtk instead?
Do you mean having py26-wxpython depend on wxgtk? I suppose that could be done if the version of wxgtk matched wxpython (currently wxgtk is an older version). However, I still think it would be better to remove wxgtk in favor of adding a gtk variant to wxWidgets. Also, eventually wxwidgets and wxpython will have cocoa support, and then the gtk toolkit will not be required for wxpython on Snow Leopard.
I'll attach a patchfile to add the gtk variant to wxwidgets.
comment:19 follow-up: 20 Changed 14 years ago by mf2k (Frank Schima)
I meant that maybe we could have wxWidgets-python depend on wxgtk. We would have to update the wxgtk port then it sounds like.
Otherwise, I'm all for removing wxgtk, but we have to modify the xchm port to work without it. The main issue I see is that xchm doesn't need python. wxgtk is a direct C++ to GTK API.
comment:20 follow-up: 21 Changed 14 years ago by jjstickel@…
Replying to macsforever2000@…:
I meant that maybe we could have wxWidgets-python depend on wxgtk. We would have to update the wxgtk port then it sounds like.
Otherwise, I'm all for removing wxgtk, but we have to modify the xchm port to work without it. The main issue I see is that xchm doesn't need python. wxgtk is a direct C++ to GTK API.
Maybe I don't understand what wxgtk is: is it not wxwidgets using the gtk toolkit? Or is it a subset of wxwidgets? If the former, then wxgtk can be replaced by wxwidgets +gtk (see the patch I attached to this ticket), and xchm can depend on that.
BTW, wxwidgets-python does not provide wxpython! It is wxwidgets but at the version number needed by wxpython.
comment:21 follow-up: 23 Changed 14 years ago by mf2k (Frank Schima)
Replying to jjstickel@…:
Maybe I don't understand what wxgtk is: is it not wxwidgets using the gtk toolkit? Or is it a subset of wxwidgets?
This is confusing to me as well. Maybe you are right.
If the former, then wxgtk can be replaced by wxwidgets +gtk (see the patch I attached to this ticket), and xchm can depend on that.
The only problem with that is that a port cannot depend on a variant. See ticket:126.
BTW, wxwidgets-python does not provide wxpython! It is wxwidgets but at the version number needed by wxpython.
I see now. This is starting to make some sense to me.
Why didn't we just update the existing wxwidgets port to 2.8.10.1 instead of adding the wxwidgets-python port again? 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.
comment:22 Changed 14 years ago by mf2k (Frank Schima)
When I said "maybe you are right", i meant that wxgtk sounds like it is wxwidgets with the gtk toolkit - i.e. essentially wxwidgets-python +gtk.
comment:23 Changed 14 years ago by jjstickel@…
Replying to 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.
comment:24 Changed 14 years ago by jjstickel@…
Or we could make +gtk to be the default variant for wxwidgets and have xchm depend on that. This may make some users of wxwidgets unhappy, though, if they prefer carbon (or cocoa).
comment:25 Changed 14 years ago by Veence (Vincent)
Resorting to gtk to build wxWidgets is indeed a waste of resources. It mean using X (that ultimately relies on carbon or cocoa), then gtk over X, then wxWigdets over gtk. At the end, we get wxWidgets/gtk2/X/cocoa (or carbon ?) instead of just wxWidgets/cocoa. You can (rightly) object that, after all, wxWidgets is just a graphical toolkit, and performance does not matter much. True, but nevertheless, it *is* a waste of material.
So it will surely work. But I think, before anything else, we should ask somebody of wxWidgets team how is wx-cocoa going, since this seems to be the major hurdle.
comment:26 Changed 14 years ago by jjstickel@…
Looks like progress stalled... Can we commit the last two patches I provide on this ticket, leave wxgtk as it is, and close the ticket? Those who want wxWidgets/wxPython on Snow Leopard can at least use the x11/gtk variants I provide here until wx-cocoa comes along.
Thanks, Jonathan
comment:27 follow-up: 30 Changed 14 years ago by totonixsame@…
Hi all,
I tried to install wxpython using this portfile with carbon variant, but I had this problem:
/Applications/wxMac/osx-build/bk-deps g++ -c -o corelib_webkit.o -I./.pch/wxprec_corelib -D__WXMAC__ -I../src/tiff -I../src/jpeg -I../src/png -DwxUSE_BASE=0 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/Applications/wxMac/osx-build/lib/wx/include/mac-ansi-release-static-2.8 -I../include -fpascal-strings -I../src/mac/carbon/morefilex -I/Developer/Headers/FlatCarbon -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing ../src/html/htmlctrl/webkit/webkit.mm ../src/html/htmlctrl/webkit/webkit.mm: In function ‘wxString wxStringWithNSString(NSString*)’: ../src/html/htmlctrl/webkit/webkit.mm:335: warning: ‘lossyCString’ is deprecated (declared at /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:368) ../src/html/htmlctrl/webkit/webkit.mm: In function ‘NSString* wxNSStringWithWxString(const wxString&)’: ../src/html/htmlctrl/webkit/webkit.mm:344: warning: ‘stringWithCString:length:’ is deprecated (declared at /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:385) ../src/html/htmlctrl/webkit/webkit.mm: In member function ‘bool wxWebKitCtrl::Create(wxWindow*, wxWindowID, const wxString&, const wxPoint&, const wxSize&, long int, const wxValidator&, const wxString&)’: ../src/html/htmlctrl/webkit/webkit.mm:439: error: ‘WebInitForCarbon’ was not declared in this scope ../src/html/htmlctrl/webkit/webkit.mm:440: error: ‘HIWebViewCreate’ was not declared in this scope ../src/html/htmlctrl/webkit/webkit.mm:442: error: ‘HIWebViewGetWebView’ was not declared in this scope ../src/html/htmlctrl/webkit/webkit.mm:445: error: ‘HIViewSetVisible’ was not declared in this scope ../src/html/htmlctrl/webkit/webkit.mm:449: error: ‘HIViewChangeFeatures’ was not declared in this scope ../src/html/htmlctrl/webkit/webkit.mm:451: error: ‘GetControlEventTarget’ was not declared in this scope ../src/html/htmlctrl/webkit/webkit.mm: In member function ‘void wxWebKitCtrl::OnSize(wxSizeEvent&)’: ../src/html/htmlctrl/webkit/webkit.mm:726: error: ‘HIViewGetRoot’ was not declared in this scope ../src/html/htmlctrl/webkit/webkit.mm:726: error: ‘HIViewConvertRect’ was not declared in this scope ../src/html/htmlctrl/webkit/webkit.mm: In member function ‘virtual void wxWebKitCtrl::MacVisibilityChanged()’: ../src/html/htmlctrl/webkit/webkit.mm:754: error: ‘IsControlVisible’ was not declared in this scope make: *** [corelib_webkit.o] Error 1
Then I tried to change the portfile, and it works! The diferences are between lines 88-92, the CFLAGS, LDFLAGS ... Here comes my portfile, or if you prefer http://paste.pocoo.org/show/223888/:
# -*- coding: utf-8; mode: tcl; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=2:ts=2:sts=2 # $Id: Portfile 67817 2010-05-18 22:24:02Z macsforever2000@macports.org $ PortSystem 1.0 PortGroup archcheck 1.0 name wxWidgets-python conflicts wxgtk version 2.8.10.1 categories graphics devel platforms darwin maintainers nomaintainer description mature cross-platform C++ GUI framework long_description wxWidgets is a mature open-source cross-platform C++ \ GUI framework for Mac OS, Unix, Linux, Windows. It can \ make use of a variety of native widget sets as well as \ its own widget set: Mac OS, GTK+, Motif, WIN32. \ wxWidgets will even run on embedded systems using \ Linux and X11. This port version is meant to be in sync with py*-wxpython. homepage http://www.wxwidgets.org/ distname wxWidgets master_sites sourceforge:wxpython use_bzip2 yes distname wxPython-src distfiles ${distname}-${version}${extract.suffix} checksums md5 65d5ef166f23fe8b4c67f58df164f93e \ sha1 6598fbafd979a91f20100171fa23a91779f6dc62 \ rmd160 bb606046d140623041b988e64ab268ced9aa958f depends_lib \ port:jpeg \ port:tiff \ port:libpng \ port:zlib \ port:libiconv \ port:expat \ path:lib/pkgconfig/sdl.pc:libsdl \ port:libsdl_mixer archcheck.files lib/libjpeg.dylib \ lib/libtiff.dylib \ lib/libpng.dylib \ lib/libz.dylib \ lib/libiconv.dylib \ lib/libexpat.dylib \ lib/libSDL.dylib \ lib/libSDL_mixer.dylib set worksrcdir ${distname}-${version}/build extract.only ${distname}-${version}${extract.suffix} patchfiles changeset_r61009.diff patch.dir ${workpath}/${distname}-${version} patch.pre_args -p4 configure.cmd ../configure configure.ldflags -L${build.dir}/lib -L${prefix}/lib configure.args --mandir=${prefix}/share/man \ --with-libiconv-prefix=${prefix} \ --with-libjpeg \ --with-libtiff \ --with-libpng \ --with-zlib \ --with-sdl \ --with-opengl \ --disable-sdltest \ --enable-unicode \ --enable-display \ --enable-monolithic set contrib "gizmos stc ogl" set installtype release build.target universal_variant no use_parallel_build no variant carbon conflicts gtk description {use carbon} { configure.args-append --with-mac if {$build_arch == "x86_64"} { configure.build_arch i386 configure.cflags-append -arch i386 configure.ldflags-append -arch i386 configure.cxxflags-append -arch i386 configure.cppflags-append -arch i386 configure.objcflags-append -arch i386 } elseif {$build_arch == "ppc64"} { configure.build_arch ppc } if {![info exists configure.ld_archflags]} { eval configure.ldflags-append ${configure.cc_archflags} } } variant gtk conflicts carbon description {use gtk} { depends_lib-append port:gtk2 depends_lib-delete path:lib/pkgconfig/sdl.pc:libsdl depends_lib-delete port:libsdl_mixer configure.args-delete --with-sdl configure.args-append --with-gtk } variant nonmonolithic description {build libraries separately} { configure.args-delete --enable-monolithic } variant debug description {add debug info to libraries} { configure.args-append --enable-debug set installtype debug } if {![variant_isset carbon]} { default_variants-append +gtk } post-configure { if {[variant_isset gtk]} { # for some reason, 'configure --with-gtk' does not specify to link the X11 opengl libs # not sure what happens if quartz variant of gtk2 is used reinplace "s|EXTRALIBS_OPENGL = |EXTRALIBS_OPENGL = -lGL -lGLU -lglut|g" ${worksrcpath}/Makefile } } post-build { foreach c { ${contrib} } { system "cd ${build.dir} && make -C contrib/src/${c}" } } post-destroot { foreach c { ${contrib} } { system "cd ${build.dir} && make -C contrib/src/${c} install ${destroot.destdir}" } xinstall -d -m 755 ${destroot}${prefix}/share/doc/${name} #xinstall -m 644 -W ${workpath}/${distname}-${version} \ # install-mac.txt install-mgl.txt install-motif.txt \ # INSTALL-OS2.txt install-x11.txt readme-cocoa.txt \ # readme-gtk.txt readme-mac.txt \ # readme-mgl.txt readme-motif.txt readme-x11.txt \ # ${destroot}${prefix}/share/doc/${name} if {[variant_isset carbon]} { set confscript ${prefix}/lib/wx/config/mac-unicode-${installtype}-2.8 } if {[variant_isset gtk]} { set confscript ${prefix}/lib/wx/config/gtk2-unicode-${installtype}-2.8 } reinplace "s|-L${build.dir}/lib||" ${destroot}${confscript} ln -sf ${confscript} ${destroot}${prefix}/bin/wx-config } livecheck.type regex livecheck.url ${homepage}/downloads/ livecheck.regex Current Stable Release.*(2\\.\[0-9\]\\.\[0-9\]+)
comment:29 Changed 14 years ago by totonixsame@…
comment:30 Changed 14 years ago by jjstickel@…
Replying to totonixsame@…:
Hi all,
I tried to install wxpython using this portfile with carbon variant, but I had this problem:
<snip>
Then I tried to change the portfile, and it works! The diferences are between lines 88-92, the CFLAGS, LDFLAGS ... Here comes my portfile, or if you prefer http://paste.pocoo.org/show/223888/:
Thanks for the report. I revised the portfile patch to include your suggested fix. Next time, please include a patch to the portfile rather than the entire portfile.
comment:31 Changed 14 years ago by jjstickel@…
As reported on ticket #24859, mesa is needed as a depends_lib for the gtk2 variant. I will revise the current working patchfile.
Changed 14 years ago by jjstickel@…
Attachment: | wxWidgets-python_Portfile.diff added |
---|
add conflict to wxWidgets and flags for i386 carbon and mesa dependency for gtk2
comment:32 follow-up: 33 Changed 14 years ago by jjstickel@…
My suggested Portfiles have now been included in for some time, and as far as I can tell, a couple additional issues have been corrected in the patches I provide here. Can a developer please commit the patches and close this ticket?
Thanks, Jonathan
comment:33 Changed 14 years ago by mf2k (Frank Schima)
Replying to jjstickel@…:
My suggested Portfiles have now been included in for some time, and as far as I can tell, a couple additional issues have been corrected in the patches I provide here. Can a developer please commit the patches and close this ticket?
r69474. I bumped the revision for the mesa dependency.
Was there any other patch you wanted committed?
comment:34 follow-up: 35 Changed 14 years ago by jjstickel@…
Thanks for committing that patch. The only other thing to do is add conflicts for wxWidgets-python and wxgtk to the wxWidgets Portfile , and to add a conflict for wxWidgets to the wxgtk Portfile.
Changed 14 years ago by jjstickel@…
Attachment: | wxWidgets_Portfile.2.diff added |
---|
adds conflicts for wxWidgets-python and wxgtk
Changed 14 years ago by jjstickel@…
Attachment: | wxgtk_Portfile.diff added |
---|
adds conflict for wxWidgets
comment:35 Changed 14 years ago by jjstickel@…
Replying to jjstickel@…:
Thanks for committing that patch. The only other thing to do is add conflicts for wxWidgets-python and wxgtk to the wxWidgets Portfile , and to add a conflict for wxWidgets to the wxgtk Portfile.
The two patches I just attached will resolve this. Please apply and close the ticket. Thanks!
comment:36 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Committed in r69923.
wxWidgets-python