Hi there
I'm responsible for the creation of the Strawberry Perl distribution ( http://strawberryperl.com/ ) and for three months during 2008 I was funded by the Perl Foundation to natively implement Portability into Perl.
I'm happy to report that (a few beta bugs notwithstanding) it was a complete success. But now I've got a bit of a problem when it comes to doing the portableapps.com packaging...
We have deep support in the Perl binary now and the CPAN client, and even the regular File::HomeDir->my_document style APIs natively report portableapps.com-compatible paths when they detect they are running in a portable context.
We even have a beta of a zip-packaged Portable Perl distribution being automatically spat out of the distribution build scripts (http://strawberryperl.com/download/strawberry-perl-5.10.0.3-portable-bet...).
My problem now, unusually, is how the hell do I build the ACTUAL portableapps.com package out of the .zip file directly?
This is a slightly unusual build (compared to what seems to be the normal process) in that I just need 100% of all the existing files, unmodified, with no registry hacks or changes of any kind, and I can't find any obvious documentation on taking this direct unmodified path to an installer.
Everything I can find to read seems to be based around converting existing non-Portable applications over into Portable form...
Got any pointers or URLs on how to go from .zip to NSI installer direct?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
Welcome Adam. You've come to the right place.
To answer your question, you need to extract the zip file and put it's contents in the \Data subdirectiory. That or you'd need to find a way to extract the contents of the zip file somewhere, run your code, compile, whatever (do the user's PERL stuff), and the then clean it all up at the end.
Strawberry PERL differs for other apps in that it doesn't have a main executable (or does it?). In the root directory of a portable app is an executable that launches the main exe and does all the setup/cleanup/storing of settings need to make it portable.
Look in the \Other\Source subdir of one of the new official portable apps and you'll see the latest launcher & installer (the latest VirtualDub just came out so try that one).
https://portableapps.com/development
If your question is, "Where do I start?"...start by decompiling one of the simpler apps' installer and launcher and coding your own stuff in their to make your own.
Hopefully someone with a little better clue comes along and answers your question too. Good luck!
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
Correct, it doesn't have a "main executable" as such.
Perl (it's not an acronym) is a language platform, in the same sense as Java or .NET doesn't have a "main executable".
The packaging process is really a test for me at this point. The distribution generator has the ability to "portablise" any variant that it builds, so once I work out how to automate the zip -> PA Installer process, what I'll probably do is move to bundling a Perl/CPAN-installed IDE on top of the base install.
http://padre.perlide.org/wiki/Screenshots
So at that point, you would end up with a "main executable" that would serve as a suitable point for a production release.
I've also noticed in that URL you mention that there is discussion of using a common run-time Perl in a Common Files directory, should I be investigating doing that?
The \CommonFiles directory is going to be where common libraries of files will go so we don't have multiple copies of libraries needed to run programs (at least that's my perception). For example, OpenOfficePortable needs the Java libraries to run it's built-in Wizards. The launcher redirects the calls to java.exe to the CommonFiles directory so it doesn't matter if the user has the Java runtime installed or not. If someone made another Java-based app portable, they should point it to \CommonFiles directory in their launcher to use the JRE installed there as well.
As far as you putting your files there, John Haller will have to comment on that so I don't give you wrong info and then you waste work/time on a dead end.
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
I thought I'd revisit this for you and take a look at what you want to do.
Correct me if I'm wrong, but Strawberry Perl is more than just a Perl interpreter, isn't it?
So, here's what you need to do:
If you've got any questions, feel free to ask.
"If you're not part of the solution, you're part of the precipitate."
There's a couple of minor issues with your suggestions.
The main one is that the way the whole native portability bootstraps.
The perl.exe will resolve it's own location in absolute terms. It will then localize it's internal (default) library search path. So moving Perl itself around isn't an option.
Once bootstrapped to this point, there's hooks in three or four modules that are essentially universal dependencies for anything filesystem related.
When these module are loaded, they start from the Perl binary location and search upwards to locate a file called portable.perl, which is known to sit in the root path of the installation. Portable.pm is loaded to read and process the contents of this file, which consists of a set of named relative paths that override certain in-memory locations for the duration of the current executable invocation.
So within the Portable tree, I need to establish a distribution root.
I assume this means the dist root is going to be App\StrawberryPerl, which means we end up with App\StrawberryPerl\perl\bin\perl.exe as the location of the actual compiler/interpreter. A typical language install has dozens of binary things anyway, so I'm assuming we DON'T want those visible.
The Data\ thing should be fine, as the File::HomeDir module is also Portable-aware and will obey whatever portable.perl tells it is the relative path to the user data directory File::HomeDir->my_data.
Other\Source looks fine
That leaves the root directory. I assume I'll have to do something like creating a specific batch script for each thing I want to be specifically runnable, which will then point into the dist root.
I guess that also likely means that I need to find a bat2exe converter and hack in icon support etc manually? Or is there a better way?
There are few things worse than Bat2Exe converters when it comes to portable use because they all have one bug - don't support paths relative to the executable.
Normally one would use %0 in batch to refer to the script or it's surroundings, but such converters spawn the to temp, so %0 gets irrelevant.
You can still use paths relative to the current directory, but it's a bad idea for general purpose programs and very bad for a scripting engine.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
Surely that just means we need to find one without the bug? Or file bug reports against them until they fix it.
The bug is unfixable unless you make a full blown compiler or interpreter. There was one. But generated 16 bit code.
The current "compilers" just wrap the script to an exectutable stub and at runtime unpack it to temp and call the command line interpreter.
Choose another language. Any that can be compiled or "compiled" I know except for MS batch, Java, C#, *.NET (*1) should be ok.
Ad. (*1): There is a compiler for .NET, but not free.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
What does you bat script do? I'd be willing to try generating NSIS code for you.
Then you won't have to hack anything.
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
I should note that we don't actually use %0 in the batch scripts, instead we're using %~dp0.
I've been experimenting with Bat_To_Exe_Converter.exe from http://www.f2ko.de/English/b2e/ and it seems to work just fine when combined with %~dp0.
Yes, sure %~dp0 is just a variant of %0
I tried this converter now:
echo %~dp0pause
Saved as c:\e.bat
Result:
// Long wait
C:\DOCUME~1\M\LOCALS~1\TEMP\A.tmp\
So I don't see how can it be fine for you.
"Those people who think they know everything are a great annoyance to those of us who do." Asimov
Thanks for the sample, I'll make up some test cases to trap this stuff and see if I can work out why it's working for me.