On Thu, Feb 24, 2011 at 9:45 PM, Mark Dootson <mark.doot...@znix.com> wrote: > Hi, > > If your end users do the install rather than having everything packaged > up in Cava, they get a working Perl + Wx + no restriction on plugins etc. > > Cava = distribute application - maybe closed source - can't run any > non-packaged Perl (by design). I'm sure this will break an attempt to > package Padre in one way or another. > > Citrus = distribute and re-distribute a predictable Perl + Wx to run > your open Perl code on. No need for Cava. Fully open source. > > I'm pretty sure you want the pure Citrus approach. > > There are some issues for Citrus regarding CPAN clients that make > assumptions about the Perl they're running in but eventually I'll trawl > the docs for each and figure out setting up an environment to make them > play nice. > > For now, good ole 'cpan' is your friend. > > Since I started writing this, a couple more list posts arrived. > I'm currently working on a Linux installer for Cava. It is a gui for > requesting install location + installation of menu items and icons in > standard free-desktop locations. I'll be able to stub a Citrus install > with it. > > In preparing Citrus, I build on Red Hat alike CentOS5 - which contains > minimum glibc + gtk I want to work with. > I then test it to ensure it works with all the distros I claim it does. > > If you build your Padre on Ubuntu 10.10, for example, you'll likely pick > up dymanic loading dependencies via built xs modules that are going to > prevent your xs modules running on older distributions. So, if you go > down the route of pre-building everything, I'd suggest CentOS5 as a > platform. > > Seems to me your best option is to tell users to > > chmod 0700 citrusperl-linux-x64-5-12 > ./citrusperl-linux-x64-5-12 -d /pathtoinstall > /pathtoinstall/CitrusPerl/x64/5-12/bin/citrusreloc > . /pathtoinstall/CitrusPerl/bin/citrusenv64 > cpan -i Padre > > > Eventually, I'll wrap this in a gui to request install path. > >
I am not sure I understand you. I don't want our user to install CitrusPerl and then cpan Padre. My hope is that we can package Padre + some of the plugins in a stand alone package that the user can install and use regardless of which version of Perl she has on the system or if she has any Perl. (ok in that case Padre will be just a bloated text editor of course). For this use case the fact that Padre is written in Perl and that it comes with its own perl does not matter. We don't want to use this perl for anything else than running Padre itself. If the user writes some perl code and she wants to run it she will have to have a "real" perl on the system. We just have to make sure padre finds it. As an exercise change the configuration option Tools/Preferences/Run Parameters/Perl Interpreter and set it to /usr/bin/perl ( I did it with another version of padre as this one is crashing when I save the preferences) When I tried to run a script using the Padre from Claudio it worked as expected as it was using the external perl for running the code. We can still let our end users also use a pure Citrus-Perl and install Padre and plugins manually and that would be also an improvement from the current situation. We should check that option as well. Gabor _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
