129492 - Need to package embed.jar on Mac for PPEmbed

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect, P1)

Description

[Mike Pinkerton (not reading bugmail)]

Mac embedding clients need Embed.jar created. Right now, it's only built on win
and unix.

It really should be done as part of our normal build process (with a build
option), but MacPerl is such the ugly step-sister. Would it be totally out of
bounds to tell people to run the scripts with cmd-line perl on OSX? Just a thought.

Comment 1

[Mike Pinkerton (not reading bugmail)]

cc'ing adam for r= of upcoming patch.

Comment 2

[Mike Pinkerton (not reading bugmail)]

Attachment: scripts to get this running on mac

this patch is in two parts:

1) changes to gen_mn.pl to break out the routines that do the work into a
package so that it can be called from a script by MacPerl as well as by the
command line from the make system. I had to tweak some things to get them
working with macperl (such as using opendir() instead of "ls -1 |", etc).

2) changes to the mac perl build scripts to use this script and mimic the
wonkyness of the win/unix embedding packaging system. don't shoot the messenger
;)

needing r/sr. if both conrad and adam could look over these, it would be great.

Comment 3

[Conrad Carlen (not reading bugmail)]

if $main::options{chrome_jars} == 0 (the way I usually build),
DumpChromeToTemp() wouldn't work. If that was the case, couldn't it just set the
temp dir to be the un-jarred chrome dir and still work?  

Comment 4

[Adam Lock]

Looks ok except for missing newline at the end of GenerateManifest.pm. It still
works on Linux/Win32 right?

r=adamlock

Comment 5

[Mike Pinkerton (not reading bugmail)]

Attachment: do the right thing if not building with jars

fix to not un-jar if building with jars.

Comment 6

[Mike Pinkerton (not reading bugmail)]

adam, i did some cursory testing with osx's command line perl, but not entirely.
do you mind giving this a quick test on win32 or unix? thanks!

Comment 7

[Conrad Carlen (not reading bugmail)]

Comment on attachment 73267 [details] [diff] [review]
do the right thing if not building with jars

r=ccarlen. Should there be a build flag "build_embedding_dist" which would turn
on "embedding_chrome", "embedding_xul", and copy PPEmbed to that location. Then
we'd have a smoketestable PPEmbed build.

Comment 8

[Mike Pinkerton (not reading bugmail)]

conrad, that's my next goal, beyond the scope of this bug ;)

Comment 9

[Adam Lock]

I'm getting this error on Win32. I won't be able to check on Linux because my
Unix is machine is currently out of action:

..\..\dist\WIN32_D.OBJ\Embed\tmpchrome\toolkit/content/global/bindings/tree.css
  inflating:
..\..\dist\WIN32_D.OBJ\Embed\tmpchrome\toolkit/content/global/bindings/wizard.xml
Too many arguments for GenerateManifest::parse_input_manifest at
GenerateManifest.pm line 142, near
"$verbose)"
Too many arguments for GenerateManifest::dump_output_manifest at
GenerateManifest.pm line 143, near
"$verbose)"
BEGIN not safe after errors--compilation aborted at GenerateManifest.pm line 238.
BEGIN failed--compilation aborted at gen_mn.pl line 7.
NMAKE : fatal error U1077: 'perl.exe' : return code '0xff'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
Studio\VC98\bin\NMAKE.EXE"' : return
code '0x2'
Stop.

Comment 10

[Mike Pinkerton (not reading bugmail)]

ok, win issues straightened out. just need to do 

+ sub GenerateManifest {

instead of 

+ sub GenerateManifest() {

with that change, it works dandy (says adam). now i just need sr.

Comment 11

[Mike Pinkerton (not reading bugmail)]

Attachment: fix () issues

Comment 12

[Simon Fraser [no longer active]]

Comments:
+sub GenerateManifest { and other subroutines.
It's better to do 
sub GenerateManifest($$$$$$$) {
because then perl can then check the number of params at compile-time (assuming
that we don't rely on variabe # params behavior).

+  open(MANIFEST, "<$manifest") or die ("Error: Cannot open manifest
\"$manifest\".\n");

MANIFEST is never closed. It's better to use local file handles too.

+1;
\ No newline at end of file

Fix this.

+  # Need to do this dynamically, because this module can be used before
+  # mozilla/config has been checked out.

Is this true in this case?

Comment 13

[Mike Pinkerton (not reading bugmail)]

Attachment: fix smfr's issues

Comment 14

[Mike Pinkerton (not reading bugmail)]

Attachment: tweak some more things for smfr ($$'s and local file handle)

address all smfr's comments in the patch, tested on win32 and macos. works just
dandy. 

smfr? can you sr?

Comment 15

[Simon Fraser [no longer active]]

Comment on attachment 73688 [details] [diff] [review]
tweak some more things for smfr ($$'s and local file handle)

That'll do, pink. sr=sfraser

Comment 16

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 73688 [details] [diff] [review]
tweak some more things for smfr ($$'s and local file handle)

a=shaver for 1.0 trunk.

Comment 17

[Mike Pinkerton (not reading bugmail)]

landed on trunk.

Comment 18

[David Epstein]

verified patch against Mozilla 1.0.0 5/14/02 build.