Attached is the script build_osx.sh. I also went though the back and forth with Paul over the past few weeks, and tried to paste the salient bits into build_osx_notes.txt.
This question gets asked often enough that it would be great to have this as a re-usable abstracted script. Between you, Paul, Ed and me, we should be able to get that done right? :) HTH, mike. mike schroeder email: m...@donor.com On Wed, Dec 2, 2009 at 8:02 AM, perltk <per...@maine.rr.com> wrote: > Hmm.... - Actually that might be even better. :-) > Could I get a hold of the script ? > > Fitting in with that, if you're interested in a C wrapper encryption > methodology, I may have something you'd be interested that we are using > quite effectively now on linux. > > Mike Schroeder wrote: > >> Do you specifically need PAR? We (donor.com <http://donor.com>) use a >> script to build a self-contained .app that gets packaged in a DMG. It is >> specific to us, but Ed (also from donor.com <http://donor.com> and also >> on this list) and I spent a bit of time over the past few weeks helping Paul >> Smith adapt that script to his own needs. Maybe someone could take what we >> have and abstract it (our version is very specific to our needs) and make it >> a general tool on CPAN to build a Mac .app / DMG for distributing wxPerl >> applications on macs? We are swamped right now so we would not get to >> making the abstracted script for some time, but we would be happy to >> contribute our existing script and be available to help whoever wants to >> abstract it... Just an alternative -- feel free to ignore this if the idea >> does not meet your needs. >> >> mike schroeder >> email: m...@donor.com <mailto:m...@donor.com> >> >> >> >> On Wed, Dec 2, 2009 at 7:35 AM, perltk <per...@maine.rr.com <mailto: >> per...@maine.rr.com>> wrote: >> >> >> Can wxPerl be made work with par/wxpar on a mac ? >> >> Pretty please? ;-) >> >> >> >> Thanks. >> >> Jeff >> >> >> >> >
(Paul, below is an overview of our OS X app build process, but after I
wrote it and reread it and your question I realized the problem you're
facing might actually have an easy solution. You really *do* have to
run wxPerl scripts using the wxPerl executable; a copy of that
executable lives in the Wx library, which is probably somewhere like
/System/Library/Perl. So that might be all you need. But on to the
overview....)
Paul, we've never had much success on OS X using PAR to build an app
directly; we build an app by hand, which downloads some supporting PAR
files to get extra modules it needs.
What I'm doing as of a couple months ago with the release of Snow
Leopard is building my own copy of wxWidgets and Perl in its own
location (I chose /opt/d3/perl and /opt/d3/wx because "d3" is the
abbreviation for our main application, but you could build them
anywhere).
I managed to dig up/hack together incantations (which I've posted to
the wxPerl list before -- I'm sure I can find them for you) which
build both wxWidgets and Perl as 32-bit applications, and against the
OS X 10.5 SDK, so as to make them a bit backwardly compatible.
I then create an application bundle by hand. Inside
Contents/Frameworks go the wx libraries; inside Contents/Resources go
the Perl modules from my build of perl in /opt/d3/perl -- all of them,
because I installed only what I needed for the application in
/opt/d3/perl. As part of the wxPerl module install, you get a wxPerl
interpreter, which ends up in:
(application
bundle)/Contents/Resources/darwin-2level/auto/Wx/wxPerl.app/Contents/MacOS/wxPerl
Inside Contents/MacOS is a script with the same name as the
application ("dasco3" in our case); it looks like this:
#!/bin/sh
BUNDLEPATH="${0%/Contents/MacOS/dasco3}"
RESPATH=$BUNDLEPATH/Contents/Resources
FWPATH=$BUNDLEPATH/Contents/Frameworks
export PERL5LIB=$RESPATH
export DYLD_LIBRARY_PATH=$FWPATH
exec $RESPATH/darwin-2level/auto/Wx/wxPerl.app/Contents/MacOS/wxPerl
$RESPATH/dwlaunch.pl
dwlaunch.pl is our actual application script. You'll notice I use the
wxPerl which lives inside the Wx perl module install to run it.
The environment variables DYLD_LIBRARY and PERL5LIB allow perl to find
the wxWidgets library and the Perl modules, respectively, in the
application bundle.
I've got a script that rolls this bundle together and packages it up
inside a DMG. Since all the stuff I built it with lives in /opt/d3, I
can test that it works independently by temporarily moving /opt/d3
somewhere else. If the application fires up then, I know it's got
everything it needs.
There may be better ways of doing it, but this is the approach that
has solved our problems so far. I'll be happy to go into more detail
and help out as you need it!
===============================================================
You're welcome, Paul! Glad it worked! RE the distribution disk image:
All you *have* to do to make a disk image is get out the Disk Utility,
use it to create a new disk image, mount it, drop in the app, maybe
with a README or something that says "drag this thing to your
applications folder), and unmount it.
Other things you can do include "convert"ing it (in Disk Utility) to a
compressed disk image, to save space, and adding custom backgrounds
and/or a shortcut to /Applications for easy dragging and dropping.
We did the latter, and it was a big learning curve to figure out how
to do it. It involved creating a directory with the background and
icon placement we wanted, by hand, in the finder, then saving a copy
of its metadata (icon placement, background, icon size, etc, living in
the file .DS_Store), so that we could build a new one, drop that
.DS_Store into it and have everything look nice.
Here are the parts of our build script which do that:
mkdir -p $DMGDIR/backgroundimage
ln -s /Applications $DMGDIR/Applications
cp icons/d3bkg.png $DMGDIR/backgroundimage/
/Developer/Tools/SetFile -a V $DMGDIR/backgroundimage
ditto build/dmg_DS_Store $DMGDIR/.DS_Store
DMGDIR is a directory which we just created, which we're going to make
the DMG out of; the background for it (d3bkg.png) happens to be in a
directory called "icons" and the saved metadata (dmg_DS_Store) happens
to be in a directory called "build." We copy those both into the
DMGDIR directory, and SetFile to make the background image folder
invisible. the saved .DS_Store already contains the information that
the background image is in a subfolder of the disk image called
"backgroundimage".
Later on in the script, after we've created the app dir and placed it
in DMGDIR, we actually create the .dmg file... first as a
read-writeable dmg, then we mount it, give it a custom icon, then we
unmount it and then convert it into a read-only, compressed DMG and
delete the old re-writable one.
# create a read-writeable dmg out of $DMGDIR in a subdir which happens
to be called "bin"
hdiutil create -imagekey zlib-level=9 -format UDRW -srcfolder $DMGDIR
-volname dasco3 -noanyowners bin/rw-$DMGNAME
# mount it
hdiutil attach bin/rw-$DMGNAME
# give it a custom icon
cp icons/VolumeIcon.icns /Volumes/dasco3/.VolumeIcon.icns
SetFile -a 'C' /Volumes/dasco3
hdiutil detach /Volumes/dasco3
# convert it to a compressed, non-readwriteable disk image.
hdiutil convert -format UDZO bin/rw-$DMGNAME -o bin/$DMGNAME
rm bin/rw-$DMGNAME
And that's pretty much it. :-)
Like I said, you may want to start simple and only add as much pizzaz
as you think is worth your time -- it doesn't have to be this
complicated. But if you want all the bells and whistles, that's how to
get them!
======================================================
Ed,
No luck building wxWidgets as non-shared. Seems a bit tricky. Would it be
possible to see your launcher "application" script so I can do something
similar?
Also do you have a link for donations? I would love to give something back to
you or your site for being so helpful and patient.
Thanks,
-Paul
Sure Paul! Here's the script we evolved:
#!/bin/sh
#
BUNDLEPATH="\${0%/Contents/MacOS/dasco3}"
RESPATH=\$BUNDLEPATH/Contents/Resources
FWPATH=\$BUNDLEPATH/Contents/Frameworks
export PERL5LIB=\$RESPATH
export DYLD_LIBRARY_PATH=\$FWPATH
exec \$RESPATH//auto/Wx/wxPerl.app/Contents/MacOS/wxPerl \$RESPATH/dwlaunch.pl
dwlaunch.pl is the application script itself.
You'll notice we had to do some shell script voodoo to get the
absolute path of the bundle itself (BUNDLEPATH) and then use that to
set the PERL5LIB and DYLD_LIBRARY_PATH variables so that Perl can find
its Perl libraries, and the Perl libraries can find their binary
library dependencies, respectively.
You could probably do this too, with your PAR-ified binary, let's
assume again it's called MyApp. You could rename it MyApp-bin, and
have a script named MyApp in Contents/Resources/MacOS.
It could go something like this:
#!/bin/sh
#
BUNDLEPATH="${0%/Contents/MacOS/MyApp}"
FWPATH=$BUNDLEPATH/Contents/Frameworks
export DYLD_LIBRARY_PATH=$FWPATH
exec $BUNDLEPATH/Contents/MacOS/MyApp-bin
And drop the missing dylibs into Contents/Frameworks.
Let me know if that works for you?
==============================================================
I had one more question for Ed,
I have added the code to create the disk image and it works great! I'm trying
to get a little fancy with my installer as you described with the background
image. I see how this is done via the disk utility UI but wasn't sure how you
generated the .DS_Store file for use in the build script. I assume it gets
generated from the disk utility...just now sure where and how.
Thanks again,
-Paul
No prob --
To get the .DS_Store I actually physically created a folder which was
set up how I liked it, in terms of icon placement, position, and
background (see
http://forums.macosxhints.com/archive/index.php/t-7033.html for some
notes about putting backgrounds on a folder by hand) -- and then I
made a copy of the .DS_Store which existed in that folder and archived
it for later use. By copying a copy of that archived .DS_Store into
another folder, it gives it all the characteristics of the original
folder you set up by hand and copied it out of.
build_osx.sh
Description: Bourne shell script
