Inclusion of wxPerl in MacOSX 10.5 / Leopard

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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
wxperl-users mailing list
wxperl-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxperl-use
rs

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

A good weekend to all.

Mark


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://sourcefor
ge.net/powerbar/db2/
> _______________________________________________
> wxperl-users mailing list
> wxperl-userslists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxperl-use
rs



------------------------------------------------------------
-------------
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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
wxperl-users mailing list
wxperl-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxperl-use
rs

On Sat, 28 Apr 2007 21:18:02 +0100
Mark Dootson <mark.dootsonznix.com> 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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
wxperl-users mailing list
wxperl-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxperl-use
rs

# from Mattia Barbon
# on Saturday 28 April 2007 02:31 pm:

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

The dotReader binary releases haven't been any sort of walk
in the park.  
A build Module::Build subclass which bundles everything into
a 
build+push scheme has been very helpful.

Perhaps if the wxPerl dist/svn included a build tool that
could create 
and upload (via svn/ftp?) a PAR for the given platform then
volunteers 
could handle the per-platform deps and QC?  Maybe even
nightly builds?

Of course, getting that all setup and tested can be a real
pain because 
you have to test on (or emulate) a box without the requisite
libraries, 
etc.

What's the chance of getting cpan testers to check those? 
Perhaps a 
wxPerlBinary dist or some sort of change to Alien which
allowed it to 
install from source/par?

--Eric
-- 
The opinions expressed in this e-mail were randomly
generated by
the computer and do not necessarily reflect the views of its
owner.
--Management
---------------------------------------------------
    http://scratchcomputing.c
om
---------------------------------------------------

------------------------------------------------------------
-------------
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://sourcefor
ge.net/powerbar/db2/
_______________________________________________
wxperl-users mailing list
wxperl-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxperl-use
rs