Sorry
for being late in answering, comments between lines below...

On 7.12.2009, at 22.58, Ryan Schmidt wrote:

> On Dec 7, 2009, at 11:15, Freek Dijkstra wrote:
> 
>> Joshua Root deferred:
>> 
>>>> 2.9.0 is already available as wxWidgets-devel.
>> 
>> Just had a quick look; the wxWidgets-devel Portfile seems to be the one by 
>> vince, which uses a subversion pre-release of 2.9.0.
>> 
>> The one I created and tested uses the actual 2.9.0 release.
This
is news to me, as when I just looked at the project site, the stable version is 
2.8.10, 2.9.0 is still a development snapshot. I may be wrong, but even 
Sourceforge package dates from the same time as the one referred to in the 
-devel Portfile. If the project has moved to another home, would be good to 
know.

Yes, I might be the one to blame about this, as I have been doing the upgrades 
most of the time with wxWidgets (my co-maintainer, mww, has several other ports 
to maintain, and other stuff to do).
>> 
>> Since stuff like wxPython depends on wxWidgets, not on wxWidgets-devel, a 
>> working Portfile for wxWidgets is really needed. Fortunately, it exists for 
>> over two months now, so one last try: could someone please upload the 
>> Portfile?
>> 
>> (if someone likes to take a stab at the still open bug that Universal does 
>> not build, that would be highly appreciated; see #20952, #21530 and #22815. 
>> That bug is present in the wxWidget Portfiles for 2.6.4, 2.8.9, 2.9.0 and in 
>> the wxWidgets-devel Portfile for 2.9.0).
> 
> -devel ports are for development versions of software. Non-devel ports are 
> for stable versions of software. This is not documented in the guide or wiki, 
> but the request to have it documented is here:
> 
> http://trac.macports.org/ticket/14540
> 
> It's usually not a good idea to update a stable port (wxWidgets) to a 
> non-stable version (2.9.0). I can't confirm your statement that 
> wxWidgets-devel is by vince and uses a Subversion pre-release of 2.9.0; as 
> far as I can tell it is maintained by jwa and was updated to the final 2.9.0 
> in r57894 three months ago. Vince has commented on the bug you're talking 
> about, though, as I'm sure you've read, and pointed out that even if we 
> update wxWidgets to 2.9.0, the released version of py26-wxwidgets will not 
> compile:
> 
> http://trac.macports.org/ticket/20952#comment:20
> 
> If we decide wxWidgets should be an exception to the rule, and update it to 
> 2.9.0, we would then have to update py26-wxwidgets and perhaps other ports 
> that depend on wxWidgets to an unstable version as well. I'm sure you can 
> appreciate that in a package manager like MacPorts where users expect to get 
> stable versions of software, it would be bad to suddenly deliver development 
> versions to them without warning. I will grant that users also expect ports 
> to work, and I see that wxWidgets 2.8 does not work on 64-bit Snow Leopard, 
> and I understand and apologize for your frustration, but you may wish to 
> direct it at the developers of wxWidgets instead and encourage them to 
> release a stable version of their software that compiles 64-bit on Snow 
> Leopard.
> 
> You're right that ports like py26-wxpython depend on port:wxWidgets and 
> therefore port:wxWidgets-devel does not satisfy that dependency. A solution 
> is to rewrite the dependency in ports like py26-wxpython, changing 
> "port:wxWidgets" to e.g. "path:bin/wx-config:wxWidgets"; this would allow any 
> port that provides ${prefix}/bin/wx-config (i.e. either wxWidgets or 
> wxWidgets-devel) to satisfy the dependency. We have done this for other ports 
> in the past. For example, my ports cairo, pango, libpixman, graphviz, php5, 
> and mysql5 all have -devel versions, and most ports that declare dependencies 
> on them do so in a way that either of them can satisfy it.
> 
> But, as mentioned above, it sounds like 2.9 may be substantially different 
> from 2.8 such that ports that work with 2.8 won't work with 2.9/2.10. We've 
> encountered that before in the upgrade from 2.6 to 2.8, which is why a 
> wxWidgets26 port was created after wxWidgets was updated to 2.8, to 
> accommodate software that hadn't been updated to work with 2.8. Maybe we need 
> to revisit the naming of these ports, and always use the branch number (i.e. 
> rename wxWidgets to wxWidgets28, rename wxWidgets-devel to wxWidgets210, 
> allow wxWidgets28 and wxWidgets210 to install simultaneously in different 
> directories, update dependencies in other ports).
> 
> I feel I should stop rambling at this point but I hope I've explained some of 
> the issues and considerations involved, though I realize I haven't provided a 
> clear answer about what should be done now, because I don't know.
> 
The reason I have not been updated wxWidgets port is that I've been quite late 
in upgrading to SL. Now I have done that, but I'm still in the process of 
upgrading my libraries &c. to work in the snowy world (well, I'm in Finland, 
so...). I noticed that the wxWidgets fold have collected a list of hints and 
tips to build wxWidgets on SL.

The big thing with wxWidgets actually is that it is moving to use Cocoa-based 
structures instead of Carbon. Hence the difficulties that hopefully can be 
overcome!

!
! Jyrki Wahlstedt
!       http://www.wahlstedt.fi/jyrki/
!
! Our life is no dream; but it ought to become one and perhaps will.
! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0  A780 6366 EFD9 
139C C386



_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Reply via email to