Re: [wxperl-users] Inclusion of wxPerl in MacOSX 10.5 / Leopard

[Mattia B. <mat...@li...>]

On Sat, 28 Apr 2007 21:18:02 +0100
Mark Dootson <mar...@zn...> wrote:

> Hmmmm....
> In view of the slightly less enthusiastic response than expected, I'll shelve this idea.
> Maybe it was a bad one anyway.

  I believe providing binary releases is a very good idea, and I also
thought of allowing side to side installation for different
wxPerl/wxWidgets combinations.  I don't think there is anything wrong
with what you write below.

  The trouble (as usual) is finding somebody to do it.  I remember it
took me a whole weekend (when everything went smoothly) to make a
wxPerl binary release for RedHat, Win32 and OS X Panther+Tiger.  I
also remember I anticipated with (almost) fear every wxPerl release,
and I am much more relaxed now that I decided not to provide binaries
myself.

Regards
Mattia
 
> Mark Dootson wrote:
> > Hi All,
> > 
> > I was reading the wxWidgets blog which says
> > 
> > "The new schedule of Apple's OS X 10.5 a.k.a. Leopard (to ship in October) allows us to get a newer version of 2.8 into the builds. So we aim for a 2.8.4 Release Candidate around the end of April, synching wxPython and wxPerl with it."
> > 
> > It left me thinking, wouldn't it be nice if as a Wx developer, I could point to a ready built Wx package that needed to be installed for a particular platform, then I could just release the perl script, or at least some sort of package that needn't include the whole of Wx, and not be concerned about other installed versions of Wx.
> > 
> > I think it would be a nice idea to have a set of packages for different platforms but all built against the same versions of Wx / wxWidgets using the same build parameters (as far as possible).
> > 
> > It would be nice to aim for a 6 monthly release schedule.
> > 
> > The packages would have to allow one release to exist alongside another, so we would have to come up with a scheme for an install location that would work on each platform. It would be easy to point your script at the desired release version by using Wx::Mini or something close to it.
> > 
> > Its a way of being able to distribute a cross platform Wx script that uses an installed perl without having to worry about building and managing the wxPerl / wxWidgets distribution itself.
> > 
> > I imagine we'd end up with something like
> > 
> > wx-binary-release-01-win.exe
> > wx-binary-release-01-sus.rpm
> > wx-binary-release-01-fed.rpm
> > wx-binary-release-01.deb
> > wx-binary-release-01-10-5.dmg (universal)
> > wx-binary-release-01-10-4.dmg (universal)
> > wx-binary-release-01-10-3.dmg (ppc)
> > 
> > and after 6 months (if its agreed that this is the right sort of period for this kind of thing)
> > wx-binary-release-02-win.exe
> > etc.
> > 
> > I think I am right in saying that the dists would also work perfectly well if you used something like PAR/pp to package everything other than Wx. You'd just include the equivalent to Wx::Mini with your PAR which would add the standard install location of the wx-binary to your @INC.
> > 
> > Does anyone think this is a good idea, and more importantly, is anyone willing to sign up to produce one of the dists and a minimal installation doc for it?
> > 
> > I know CPAN works just fine so long as you are in control of the Perl installation, and would always be the preferred method if you are. But where you aren't in control there are many complications that I think the above would solve.
> > 
> > If you think the idea is really bad, please let me know too. You may be right!
> > 
> > Regards
> > 
> > Mark