Mojca
Your efforts to sort this out are appreciated. wxwidgets and wxpython
are a headache and poorly developed and maintained upstream (IMO).
I am the maintainer for several enthought ports that depend on wx or QT4
(py-pyface being most relevant). Historically, Enthought's support for
wx was better than for QT4, but with wx-2.8 not working with 64-bit
architecture, that has changed. Therefor, QT4 now seems to be the
preferred backend:
https://support.enthought.com/entries/22601196-wxPython
For py-pyface, I make pyqt4 the default variant and wx is there as an
option should anyone want to use it on 32-bit systems. However, I have
not tested nor plan to test the wx variant, and so I have no idea if it
even works. My point is this: because of the trouble with wx, I expect
that it will slowly fade away. Projects that use it will start to use
alternative backends. I could be wrong totally wrong, but I suspect this
is part of the reason you are not receiving much response from Macports
developers.
Some more comments interspersed below.
Jonathan
On 8/13/13 10:52 , [email protected] wrote:
Date: Tue, 13 Aug 2013 15:10:27 +0200
From: Mojca Miklavec<[email protected]>
To: MacPorts Development<[email protected]>
Subject: Re: wxWidgets again
Message-ID:
<CALBOmsZ1CSfa4ne6VOqFk2aeP5sw1M_P=zeqwltmoxdkerv...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
since I would like to proceed with testing, I would really be grateful
for a bit of your help and opition, mainly: how to call the wxWidgets
variants of ports which depend on wxWidgets and how to properly put
constraints into the PortGroup?
My idea is the following:
(1) all dependencies that work with 2.9 should depend on 2.9 only
(2) all dependencies that only work with 2.8 should depend on 2.8, but:
(a) on 10.8 and later and on Xcode 4.4 or later they have to depend
on wxgtk-2.8
(b) on 10.7 with Xcode 4.3 or earlier they can depend on 32-bit carbon
My questions:
(i) How would you call the port variants?
(ii) In case of (2b) the port needs to declare things like
supported_archs i386 ppc
# somewhere in pre-fetch
if {${os.major} >= 12 || [vercmp $xcodeversion 4.4] >= 0} {
return -code return "won't work"
}
I would like to put this into PortGroup. How?
Thank you,
Mojca
On Sun, Aug 11, 2013 at 5:18 PM, Mojca Miklavec wrote:
>Hi,
>
>After some playing with wxWidgets, this is where I managed to come.
>Instead of the following ports (each conflicting with each other):
>- wxgtk (2.8)
>- wxWidgets (2.8)
>- wxWidgets-python (2.8, with gtk)
>- wxWidgets30 (2.9)
Despite what is stated on the wxWidgets website, I doubt that 3.0 will
be available soon. As even stated on the wxWidgets roadmap, it has been
7 years since the release of stable 2.8!
>- wxWidgets-devel (2.9)
>
>I created a bunch of ports that can be installed independent from each other:
>- wxWidgets-2.8 (2.8; with gtk)
> - (planned subport) wxgtk-2.8
>- wxWidgets-3.0
>- wxPython-3.0
>
>The port "wxWidgets-python" is not really needed. The only difference
>in functionality of the current port is that it provides gtk, but that
>can already be provided by wxWidgets-2.8 (or its planned subport
>wxgtk-2.8).
I created wxWidgets-python precisely for the reason mentioned next:
versions of wxWidgets and wxPython are often out-of-sync. This can be a
huge problem and needs to be dealt with carefully. It boggles my mind
why the developers of wxPython think it is OK to do this.
>
>The port wxPython-3.0 is there for one single reason: because releases
>of wxWidgets and wxPython are often out-of-sync, but the ports are
>otherwise independent.
>
>The port wxgtk can go and can be replaced with a subport of
>wxWidgets-2.8. I managed to compile wxWidgets also with a flag
>--enable-graphics_ctx and if it's compiled with GTK2/X11, it can
>easily be compiled on any Mac OS X, also as 64-bit, not just on 10.6
>and lower as 32-bit. I tried compiling with GTK2/Quartz, but I believe
>that more work would be needed to get there since wxWidgets make some
>weird assumptions (just as an example: even when compiling with GTK on
>Mac, wxWidgets don't add OpenGL flags from mesa, assuming that those
>are not needed).
It seems that no one really wants X11 as part of a backend when there
should be alternatives. This is the reason I personally abandoned wx
backend and started using QT4 for enthought ports.
>
>I need help with coming up with a slightly better PortGroup, but I
>would like to proceed as follows:
>- all dependencies that work with 2.9 should depend on 2.9
>- all dependencies that only work with 2.8 should depend on 2.8, ...
>- BUT: I would like to offer the choice (an extra variant) to allow
>the user to switch between 32-bit Carbon variant and possibly 64-bit
>or universal GTK/X11 variant of wxWidgets 2.8, so that all these ports
>would also compile on OS X >= 10.7
>
>I tried compiling FileZilla. It compiles fine on 10.7 as 64-bit, but
>apparently it ends up with
> /opt/local/bin/filezilla
> /opt/local/bin/fzputtygen
> /opt/local/bin/fzsftp
>along with plenty of other files as opposed to FileZilla.app. But at
>least it works. Similar "problems" might arise with other ports.
>
>My question is: how would you call these port variants to switch
>between Carbon and GTK/X11 of wxWidgets 2.8?
>
>Mojca
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
