132946 - jar packaging scripts cannot be run from any directory

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[Alec Flett]

So a certain embedding client needs to be able to run the packaging scripts from
directories in their own build tree...

I've hacked up the scripts so they will pull in an "requires" packages from the
same directory that the script was run from. (Thanks to jgrm for a little help
on this one)

I'm cc'ing pinkerton, because one of the problems was thanks to some of his
hacking earlier this milestone :)

Comment 1

[Alec Flett]

Attachment: make the scripts runnable from anywhere

here we go.. just using perl's built in FindBin package. Reviews?

Comment 2

[Mike Pinkerton (not reading bugmail)]

uh, how did the changes i make cause this? nothing in the patch suggests it :(

Comment 3

[Alec Flett]

Attachment: oops.. include gen_mn.pl

oops! I left out the one part of the patch that you'd recognize.. :)

ok what was basically going on was the embeddor's scripts were jumping through
hoops just to call make-jars.pl, because it used "require" to pull in
mozLock.pm.. 

now gen_mn.pl brings in GenerateManifest.pm, which means that we were going to
have to hack the embeddors scripts even more in order to keep calling
gen_mn.pl. So I fixed gen_mn.pl, and then figured I'd fix the mozLock require
line, so that we could remove all the hacks from the embeddors scripts.

With this patch, I've made both scripts pretty self-contained (i.e. you just
run perl <scriptname>, no matter what directory you're in)

while I was there, I fixed a bug in mozLock.pm that was causing silent failures
on windows if WINOS wasn't defined. a zero-length substr() of any string will
always be the empty string. Chris - I know we talked about mozLock not being
required on Windows, but the last bit prevents a silent failure if WINOS isn't
set right..

So there we go. Now can I get reviews? :)

Comment 4

[hacker formerly known as [e-mail]]

Comment on attachment 76040 [details] [diff] [review]
oops.. include gen_mn.pl

r=cls

Comment 5

[Kevin McCluskey (gone)]

embed triage: topembed+

Comment 6

[Mike Pinkerton (not reading bugmail)]

+require GenerateManifest;
+import GenerateManifest;
 use Getopt::Long;
-use GenerateManifest;

so teach me, oh wise perl masters. what is the difference here?

Comment 7

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 76040 [details] [diff] [review]
oops.. include gen_mn.pl

i understand now, r=pink

Comment 8

[Asa Dotzler [:asa]]

Comment on attachment 76040 [details] [diff] [review]
oops.. include gen_mn.pl

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 9

[Alec Flett]

yay, finally found an open tree. fixed.

Comment 10

[hacker formerly known as [e-mail]]

So, this is breaking the OS/2 builds.  It appears as though it may be due to a
bug in their FindBin.pm implementation but we should be aware of it.


Cannot chdir to
E:/OS2_2.40_Clobber/mozilla/obj/xpcom/base/E:/OS2_2.40_Clobber/mozilla/config/:No
such file or directory at e:/PERLLIB/LIB/5.00553/FindBin.pm line 181
BEGIN failed--compilation aborted at e:/PERLLIB/LIB/5.00553/FindBin.pm line 185.
BEGIN failed--compilation aborted at
E:/OS2_2.40_Clobber/mozilla/config/make-jars.pl line 6.
gmake.exe[4]: *** [libs] Error 2
gmake.exe[4]: Leaving directory `/OS2_2.40_Clobber/mozilla/obj/xpcom/base'

Comment 11

[Mike Kaply [:mkaply]]

I was thinking maybe it was the trailing slash on the directory name.

I'll look at this when I get in to work and have an OS/2 machine in front of me.

Comment 12

[Mike Kaply [:mkaply]]

We were able to fix this by changing FindBin.pm.

If there is a way to fix it in Mozilla, we'd love to fix it there :)

In the function is_abs_path, we had to add an OS/2 path that was the same as 
Windows.

sub is_abs_path
{
 local $_ = shift if (@_);
 if ($^O eq 'MSWin32')
  {
   return m#^[a-z]:[\\/]#i;
  }
 elsif ($^O eq 'os2')
  {
   return m#^[a-z]:[\\/]#i;
  }
 elsif ($^O eq 'VMS')
  {
    # If it's a logical name, expand it.
    $_ = $ENV{$_} while /^[\w\$\-]+$/ and $ENV{$_};
    return m!^/! or m![<\[][^.\-\]>]! or /:[^<\[]/;
  }
 else
  {
   return m#^/#;
  }
}

Comment 13

[Alec Flett]

sounds like its time to submit a patch back to the perl for os/2 authors :)
but seriously, I'm not sure what to do here. FindBin is the right package here,
it seems wrong to try to copy and paste FindBin code into our scripts, so I'm
not sure what to do here...are you sure you have the latest perl? (I'm using
5.6.1) - though I'd more likely believe that someone simply overlooked this in
the os/2 port

Comment 14

[Mike Kaply [:mkaply]]

I'm fine with fixing this on the tinderboxes and putting on the OS/2 port page 
as a change.

I'm currently doing a trunk build with the change to make sure it fixes 
everything.

Comment 15

[sobotka]

None of the FindBin.PM's I have here (version 1.42 with Perl 5.6.1 and 5.7.2,
and 1.43 with 5.7.3) contain the is_abs_path sub and their code ends before line
180, so the bug may be gone. If it's still there, I'll hit it on my next build
and can fix it for 5.8.0 (due this month or next). For 5.00x users, I would
suggest adding a note about the required fix (which can be reduced to adding "||
$O^ eq 'os2'" to the MSWin32 condition) to the build instructions.