proposed new Portfiles for wxWidgets and wxPython

[jjstickel@…]

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.

[jjstickel@…]

wxWidgets-python

[jjstickel@…]

patchfile for wxWidgets-python

[jjstickel@…]

py26-wxpython

[jjstickel@…]

patch for py26-wxpython

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

[michaelld@…]

Cc Me!

[hmng@…]

Cc Me!

[macports@…]

Cc Me!

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

[guillaume.salagnac@…]

Cc Me!

[macsforever2000@…]

Cc Me!

[macsforever2000@…]

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.

[macsforever2000@…]

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.

[macsforever2000@…]

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.

[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

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

[macsforever2000@…]

I added the conflict in r67817 and r67818. Yes, the ports are essentially the same thing. The only port that depends on wxgtk is xchm and I verified that it works with wxWidgets-python +gtk. I think putting a path dependency in xchm will be good enough for now.

[macsforever2000@…]

See #24946 for my proposed change to the xchm portfile.

[macsforever2000@…]

Can you modify wxWidget-python to include use wxgtk instead?

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

[jjstickel@…]

added gtk variant

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

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

[macsforever2000@…]

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.

[macsforever2000@…]

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.

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

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

[vince@…]

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.

[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

[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\]+)

[totonixsame@…]

Cc Me!

[totonixsame@…]

It is because this  http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard

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

[jjstickel@…]

As reported on ticket #24859, mesa is needed as a depends_lib for the gtk2 variant. I will revise the current working patchfile.

[jjstickel@…]

add conflict to wxWidgets and flags for i386 carbon and mesa dependency for gtk2

[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

[macsforever2000@…]

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?

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

[jjstickel@…]

adds conflicts for wxWidgets-python and wxgtk

[jjstickel@…]

adds conflict for wxWidgets

[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!

[ryandesign@…]

Committed in r69923.