75687 - need mechanism for creating flat chrome as symbolic links

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Robert Ginda]

configure-ing with --disable-jar-packaging used to create symbolic links into
dist/bin/chrome/foo, now it just copies.  Symbolic links made it possible to
update a xul app and test the changes without having to make all over again (on
linux, at least.)

waaa.

Comment 1

[Robert Ginda]

This fixes it, but probably breaks XP, how do we figure out if we're on *nix
here?  How about <http://lxr.mozilla.org/mozilla/source/js/tests/jsDriver.pl#730>?

cvs server: Diffing .
Index: make-jars.pl
===================================================================
RCS file: /cvsroot/mozilla/config/make-jars.pl,v
retrieving revision 3.36
diff -u -r3.36 make-jars.pl
@@ -220,7 +220,12 @@
             mkpath($dir, 0, 0775) || die "can't mkpath $dir: $!";
         }
         unlink $destPath;       # in case we had a symlink on unix
-        copy($file, $destPath) || die "copy($file, $destPath) failed: $!";
+
+        if ($fileformat eq "flat") {
+            symlink ("$objdir/$srcFile", "$objdir/$destPath") || die "symlink
($objdir/$srcFile, $objdir/$destPath) failed: $!";
+        } else {
+            copy($file, $destPath) || die "copy($file, $destPath) failed: $!";
+        }
 
         # fix the mod date so we don't jar everything (is this faster than just
jarring everything?)
         my $atime = stat($file)->atime || die $!;

Comment 2

[cls]

The use of --disable-jar-packaging is deprecated, use
--enable-chrome-format=flat instead.   I don't believe make-jars.pl ever used
symlinks.  So when we switched to using make-jars.pl for chrome exclusively
(well over 6 months ago), we stopped making symlinks for chrome.  I also recall
there being a problem with chrome symlinks and the commercial tree and I don't
want to revisit it.  Doing a 'make install' from the directory that contains the
jar.mn file is not that big of a penalty.  Marking wontfix.

Comment 3

[Robert Ginda]

Resummarizing.

Clearly you don't spend much time developing XUL applications ;)

Not typing "make install" means I just hit "reload" to get mozilla to see my
changes, typing "make install" in some other window is 100% more work. 
Seriously, it's a big win for anyone developing a mostly-xul application on unix.

How about this patch instead, it adds a new fileformat called "symlink".  People
developing xul on commercial can just stick with the "flat" format when they
need flat chrome files.  This also eliminates the need for o/s detection.

(my tree is in flux, I havn't actually tested this diff yet)

Comment 4

[Robert Ginda]

Attachment: patch to add "symlink" chrome filetype

Comment 5

[Jon Granrose]

verified wontfix.

Comment 6

[Robert Ginda]

That's it?
Happy freaking easter to you too.

Comment 7

[cls]

No, it's happy freaking birthday to me, thank you very much.  No, I'm not a XUL
developer so I don't see the pressing need for symlinks.  Your patch is untested
so I'm not going to plop it in the tree just yet.  I have negative time to put
in on this patch and it's nowhere near essential so it's going to remain at the
bottom of my
bugs-that-people-consider-cool-but-don't-have-time-to-properly-fix-themselves-and-yet-expect-me-to-fix
pile.

Comment 8

[Robert Ginda]

This isn't a bug I'm expecting you to fix.

Comment 9

[Robert Ginda]

Reassign to myself.

Comment 10

[Robert Ginda]

Attaching updated patch.

configure.in needed to allow "symlink" as a possible value for
$MOZ_CHROME_FILE_FORMAT, and the test in rules.mk needed to call add-chrome.pl
with disableJarPackaging set for the symlink case.

I also removed one of the duplicate "use Cwd;"s in make-jars.pl.

looking for r/sr=

Comment 11

[Robert Ginda]

Attachment: updated patch

Comment 12

[Robert Ginda]

ok, I flubbed this again.  For the case where there is no explicit source in the
jar.mn, $srcFile is empty, and the link ends up getting created to the
directory.  I've got the fix here, but don't have time to recreate the patch
(jsdebugger changes are mixed in.)   I'll attach it by Monday.

Comment 13

[Robert Ginda]

Attachment: another updated diff

Comment 14

[Robert Ginda]

This latest patch fixes the problem for jar.mn entries without explicit source
files.

Comment 15

[Daniel (Leaf) Nunes]

Just out of curiousity, why the removal of "use Cwd;"?

Comment 16

[Robert Ginda]

It was in there twice.

Comment 17

[Daniel (Leaf) Nunes]

r=leaf

Comment 18

[Benjamin Smedberg]

Attachment: add --enable-chrome-format=symlink

I would like to resurrect this bug... I have fixed merge conflicts above.

Comment 19

[Benjamin Smedberg]

rginda: can I steal this bug from you?

Comment 20

[Tim]

Comment on attachment 125087 [details] [diff] [review]
add --enable-chrome-format=symlink

>Index: config/make-jars.pl

> if ("$fileformat" ne "jar" &&
>     "$fileformat" ne "flat" &&
>     "$fileformat" ne "both") {
>-    print "File format specified by -f option must be one of: jar, flat, or both.\n";
>+    print "File format specified by -f option must be one of: jar, flat, both, or symlink.\n";
>     exit(1);
> }

It looks like it would always error out in the symlink case, since the if
condition doesn't check for symlink.

Comment 21

[Robert Ginda]

Benjamin, feel free.

Comment 22

[Benjamin Smedberg]

Comment on attachment 125087 [details] [diff] [review]
add --enable-chrome-format=symlink

OK, this patch is doing absolute symlinks, and I would like relative... fix
upcoming.

Comment 23

[Benjamin Smedberg]

taking

Comment 24

[Benjamin Smedberg]

Attachment: --enable-chrome-format=symlink

Updated, now uses relative symlinks. Weirdal: the check in make-jars.pl is
correct, because it checks for the "symlink" case just above and changes the
param  to "flat".

Comment 25

[Benjamin Smedberg]

Comment on attachment 125299 [details] [diff] [review]
--enable-chrome-format=symlink

cancelling reviews on this, because the relative symlinks don't work correctly

Comment 26

[[e-mail]]

Attachment: My go at a patch

Comment 27

[Benjamin Smedberg]

Comment on attachment 134062 [details] [diff] [review]
My go at a patch

please prefix rel2abs and abs2rel (mozrel2abs, for example).
File::Spec::Functions can cause name collisions in some circumstance.
Otherwise, great! r=bsmedberg

Comment 28

[Brian Ryner (not reading)]

Comment on attachment 134062 [details] [diff] [review]
My go at a patch

>Index: rules.mk
>===================================================================
>RCS file: /cvsroot/mozilla/config/rules.mk,v
>retrieving revision 3.420
>diff -p -u -r3.420 rules.mk
>--- rules.mk	16 Oct 2003 06:46:50 -0000	3.420
>+++ rules.mk	24 Oct 2003 20:36:23 -0000
>@@ -1465,7 +1465,11 @@ JAR_MANIFEST := $(srcdir)/jar.mn
> ifeq (flat,$(MOZ_CHROME_FILE_FORMAT))
> _JAR_REGCHROME_DISABLE_JAR=1
> else
>+ifeq (symlink,$(MOZ_CHROME_FILE_FORMAT))
>+_JAR_REGCHROME_DISABLE_JAR=1
>+else
> _JAR_REGCHROME_DISABLE_JAR=0
>+endif
> endif
> 
> ifdef NO_JAR_AUTO_REG

This can be written a little more concisely:

ifneq (,$(filter flat symlink,$(MOZ_CHROME_FILE_FORMAT)))
_JAR_REGCHROME_DISABLE_JAR=1
else
_JAR_REGCHROME_DISABLE_JAR=0
endif

Other than that, sr=bryner (with bsmedberg's comments addressed)

Comment 29

[[e-mail]]

Taking.

Comment 30

[[e-mail]]

Fix checked in.