[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
[MacPerl] Droplet for Standalones, thanks to Chris and (unknown)
Hi,
I could not find out if somebody else answered to this request, but I wanted
to say (very late) thank«s to Chris Nandor and ??? who sent me an email (but I
lost his email address, he was from Germany) and to summarize their answers
about this issue:
(When I finally realized how it works, it turned out to be easy and comfortable)
My problem was, that I thought it is a hassle to go through this "put the
modules you need into the resource fork" procedure again, everytime I have to
respin or fix a bug.
Now it is so easy: just using ResEdit, opening the main text resource "!",
replacing the previous perl code with the changed one, that«s it.
To help others, that might missed the mails, I paste the history of mails
below, with several explanations and the code from Chris Nandor.
Hope it helps more than it is confusing.
Best regards,
Toni
Strider wrote:
>
> Can anyone point me toward the utility (I think someone here said that it's
> a droplet) that imports all the necessary libraries into a standalone's
> resource fork?
>
> Thanks,
> Strider
>
> - I hope you recognize what you're looking for when you find it.
>
> ***** Want to unsubscribe from this list?
> ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch
-------------- MAIL 1: (answer from Chris)
Runtimes do not, by default, have access to libraries and modules that you
include. If you make the script below into a droplet and drop your saved
runtime on to it, it should work. Or, by hand, you can save the text of
each module/library in the TEXT resource of your runtime, and give it
relative name of that module/library: i.e., StandardFile.pl would just be
StandardFile.pl, but Mac::StandardFile would be Mac:StandardFile.pm.
Also, Mac::StandardFile is the better way to do StandardFile stuff for the
most part. It is documented in the Toolbox Modules chapter of the book,
draft chapter available online (URL below). The problem then will be that
Mac::StandardFile requires a shared library under PPC and CFM-68K, which
cannot be included in the runtime.
A way around this is to install a 68K-only version of the BigMacPerl
application (I just install the FAT version of it and then use a program
called StripPPC to strip out the PPC code). If saved with with BigMacPerl
68K, the "shared libraries" are linked statically into the code and the app
doesn't have to go anywhere to get them. This will be the case with the
FAT version of BigMacPerl too, but with the FAT version it will look for
the shared libraries on a PPC but not on a 68K. So the only downside is
that you will have to run in 68K emulation on a PPC machine.
-------------- MAIL 2:
At 10.12 98.02.03, Toni Zollikofer wrote:
>Can I test it only on a machine that does not have the MacPerl package on it?
>I have a PowerPC, but I guess even if it is a fat binary, both embedded
>executables would access the statically linked libraries, right?
>Or is just this library not linked in?
The BigAppl has 68K and PPC code. The 68K version of the code has the
static libraries, the PPC version uses dynamic libraries. You can either
install it (non-FAT) on a 68K machine and use that version, or you can use
a utility (I have one called StripPPC and another called Strip68K) that can
strip the offending code out. I have a special version of BigMacPerl (FAT)
that I dropped on StripPPC and now it is 68K-only.
Of course, always make sure you can restore the app if something goes wrong
with such an operation.
>>The script to save the TEXT libraries in the resource fork has been posted
>>many times, and is also on the MacPerl CD-ROM (ExtractModules is its name).
>>If you need it, I can e-mail it to you. The only thing this droplet does
>>not do for you is it does not embed autoloaded files ... if it still says
>>it can't find files after you run the droplet, you can just add those extra
>>ones by hand, using ResEdit. You should see, in the TEXT resource, how it
>>all works.
>
>I have looked at your script, but it only replaces the files, that are
>mentioned in the script itself, it does not walk through recursively, right?
I did not write ExtractModules, but now, it goes through and gets all
modules and require'd files through the tree. If you use a module that
uses other modules, it gets em all.
-------------- MAIL 3:
Here is the text of that script. Just save it as a droplet. I don't have
it on my site, I am not sure if it is available online somewhere.
(Comment from Toni: This does most of the work, if there is still an error
reported during runtime, write down what it claims it missing, and place it
into a new resource module, named after the file path the error message reported.)
#"ExtractModules.dp"
#=========================================
#!perl
use Mac::Resources;
use Mac::Memory;
#ARGV now in scalar context (thanks to Bart and Chris)
$res= OpenResFile($ARGV[0]) || die $^E;
#first 'TEXT' resource is source code:
$sourceCodeRes= Get1IndResource('TEXT', 1);
$sourceCodeText= $sourceCodeRes-> get();
#clear the hash:
undef(%INC);
#suppress warnings about redefining subroutines
#by 'eval(use...)':
local $^W = 0;
#angle operator doesn't work here(?):
@sourceCodeText= split /\n/, $sourceCodeText;
for (@sourceCodeText){
if(/^use.*;/){
eval($_); #read the %INC
}
}
$id= 5000;
foreach $libFileName(keys %INC) {
$aText= "";
open(libFile, $INC{$libFileName}) or die $^E;
while(<libFile>){
$aText.= $_;
}
$codeHand= new Handle($aText);
#UNIX-> Mac Folder
$libFileName=~ s/\//:/g;
AddResource($codeHand, 'TEXT', $id, $libFileName) or die $^E;
WriteResource($codeHand) or die $^E;;
ReleaseResource($codeHand) or die $^E;;
$codeHand-> dispose;
$id++;
print "Copied module ".$libFileName." into resource fork.\n";
}
CloseResFile($res);
sleep(3);
&MacPerl'Quit(3);
***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch