[mach-0] Use rsync to populate app package.



Build Config
16 years ago
14 years ago


(Reporter: Conrad Carlen (not reading bugmail), Assigned: Conrad Carlen (not reading bugmail))


Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)

1.08 KB, patch
hacker formerly known as seawood@netscape.com
: review+
Brian Ryner (not reading)
: superreview+
Details | Diff | Splinter Review


16 years ago
rsync can sync two local directories and is ideal for copying the contents of
dist/bin -> dist/Mozilla[Debug].app/Contents/MacOS.

current: cp takes 60 secs.
with patch: rsync, after initial pass, takes < 5 secs.

It's possible to use the --delete flag with rsync which will sync the two
exactly, deleting files in dest which aren't in src. Problem is, that deletes
component.reg so the next launch is slow. Maybe it's better to add a clobber
target to this makefile which would delete the app bundle?

I'm assuming rsync exists on 10.1 as well. Chris, can you confirm? If not, this
will need some config tests.

Comment 2

16 years ago
Created attachment 106672 [details] [diff] [review]
adds clobber

Adds clobber. The old way clobbered the bundle on every build. This allows it
when you specify it :-)
Attachment #106664 - Attachment is obsolete: true
Yes, 10.1 has rsync.  Startup times would be impacted even without the --delete,
right?  Timeless added that rules which adds the .autoreg file to $(DIST)/bin. 
Because of it's placing, it gets added after Mozilla.app is created the first
time.  But subsequent runs with the new patch will cause it to be rsync'd and
force component registration.

Comment 4

16 years ago
After the 1st build, without --delete, there's no full component registration
because compreg.dat is still there. Since rscync only updates what's changed,
only components which were rebuilt are re-registered (what we want).

Comment 5

16 years ago
OK, now I see what .autoreg does.
For Mach-0, .autoreg is irrelevant, with or without this patch. Currently,
"touch $(DIST)/bin/.autoreg" happens after the app bundle is built, so .autoreg
never ends up in dist/Mozilla[Debug].app/Contents/MacOS.
Comment on attachment 106672 [details] [diff] [review]
adds clobber

Actually, it does become relevant whenever we stop automatically clobbering
dist/Mozilla.app.  It would just take effect one cycle later. We should
probably reorder that rule so that it occurs before .app is packaged.
Attachment #106672 - Flags: review+

Comment 7

16 years ago
Created attachment 106711 [details] [diff] [review]
reorders touch of .autoreg

I reordered it now since, with the patch, we're no longer clobbering
dist/Mozilla.app. Also, made a "clean" rule as a synonym for "clobber."

With that, here's how to make use of this change:
If you're using a Project Builder project for debugging
(http://www.mozilla.org/ports/fizzilla/DebugMach.html, the section Building
From Within ProjectBuilder), you can set the directory to
mozilla/xpfe/bootstrap, the build command to usr/bin/make, and arguments to
$ACTION. Now, after changing some component, Build & Debug from PB is nice &


16 years ago
Attachment #106672 - Attachment is obsolete: true


16 years ago
Attachment #106711 - Flags: superreview?(bryner)
Comment on attachment 106711 [details] [diff] [review]
reorders touch of .autoreg

Hm. I'd prefer if the components directory still contained symlinks in the app
package.  That would eliminate the need to make in xpfe/bootstrap when
debugging and testing.	It might also make sense to have 'chrome' be a symlink
back to dist/bin/chrome, so that you don't have to rebuild in xpfe/bootstrap
after changing chrome.

Comment 9

16 years ago
> That would eliminate the need to make in xpfe/bootstrap when
debugging and testing.

But, the point is, this patch makes that quick and painless.
Attachment #106711 - Flags: superreview?(bryner) → superreview+

Comment 10

16 years ago
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.