On Sat, 28 Apr 2007 21:18:02 +0100
Mark Dootson <mark.dootson@xxxxxxxx> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
|
| 
