jar packaging scripts cannot be run from any directory

RESOLVED FIXED in mozilla1.0

Status

P1
normal
RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: alecf, Assigned: alecf)

Tracking

({topembed+})

Trunk
mozilla1.0
x86
Windows 2000
topembed+

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

17 years ago
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 :)
(Assignee)

Comment 1

17 years ago
Created attachment 75710 [details] [diff] [review]
make the scripts runnable from anywhere

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

Updated

17 years ago
Status: NEW → ASSIGNED
Keywords: topembed
Priority: -- → P1
Target Milestone: --- → mozilla1.0
uh, how did the changes i make cause this? nothing in the patch suggests it :(

Updated

17 years ago
Summary: packaging scripts cannot be run from any directory → jar packaging scripts cannot be run from any directory
(Assignee)

Comment 3

17 years ago
Created attachment 76040 [details] [diff] [review]
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? :)
Attachment #75710 - Attachment is obsolete: true
Comment on attachment 76040 [details] [diff] [review]
oops.. include gen_mn.pl

r=cls
Attachment #76040 - Flags: review+
embed triage: topembed+
Keywords: topembed → topembed+
+require GenerateManifest;
+import GenerateManifest;
 use Getopt::Long;
-use GenerateManifest;

so teach me, oh wise perl masters. what is the difference here?
Comment on attachment 76040 [details] [diff] [review]
oops.. include gen_mn.pl

i understand now, r=pink

Comment 8

17 years ago
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
Attachment #76040 - Flags: approval+
(Assignee)

Comment 9

17 years ago
yay, finally found an open tree. fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
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'
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.
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#^/#;
  }
}
(Assignee)

Comment 13

17 years ago
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
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

17 years ago
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.