Closed Bug 55778 Opened 24 years ago Closed 22 years ago

numerous dead Makefiles due to jarring changes

Categories

(SeaMonkey :: Build Config, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED WONTFIX
mozilla1.0.1

People

(Reporter: bryner, Assigned: bryner)

Details

Attachments

(4 files)

Since make-jars.pl now handles copying of files to dist/bin/chrome, there are MANY resources directories which we now either descend into needlessly or still have dead Makefiles hanging around in. I'm attaching a patch that attempts to resolve this. The net benefit is that we can remove 640 files from the tree and we don't waste time entering directories, doing nothing, and leaving. This also fixes a problem where the Windows version of platformMailnewsOverlay.xul is packaged on ALL platforms. To apply this, go to the directory ABOVE your mozilla directory, and run (on unix): POSIXLY_CORRECT=1 patch -p0 < cleanup.diff cat remove.list | xargs rm Copy the attached jar.mn file to mailnews/base/resources/content/{mac,unix,win} Not sure what the best way is to apply this on Win or Mac. Patch tested on Linux.
Attached patch cleanup.diff (deleted) — Splinter Review
Attached file remove.list (deleted) —
Status: NEW → ASSIGNED
bryner: Before we do this, you might want to ask chrome developers if they would prefer to be able to "make chrome" from each leaf directory. What I mean here is breaking up the jar.mn files into their smallest granularity so that if you touch a chrome file in a directory, you can make in that directory and have the change copied to dist, rather than the situation now where you have to cd up several levels to where the jar.mn is and make in there.
ok, so I propose we land the changes now to not descend into the directories, but hold off deleting the Makefiles until we have a decision about this. We can also remove all the MANIFEST files now (since there's no way to do a per-directory build on Mac, afaik), and we should probably try to get the fix for platformMailNewsOverlay.xul in. what do you think warren?
I think not building the dead directories is ok for now, but I'm cc'ing some chrome guys to see what they think about breaking up the jar.mn files to be smaller granularity.
we really should clean this up, and this is a pretty safe fix. -> mozilla 0.9.
Target Milestone: --- → mozilla0.9
so warren, do I have an r= on landing JUST the parts of this patch to not descend into the subdirs?
Attached patch Updated cleanup patch (deleted) — Splinter Review
cls, I can't actually test this out until 11/26 or so, but looks good... except you seem to have included some patches in there for unrelated things.
bryner: I've gone over the patch, r=dprice for cleanup.diff cls: I've been out of the loop on jar packaging for a while. What problems were we running in to that we needed to implement lockfiles in make-jars.pl?
sr=cls
sspitzer offered to help clean up mailnews on mac and windows
I'll help clean this up, but it will be a while before I have the time to get to it.
based on sspitzer's comments, -> 1.0
Target Milestone: mozilla0.9 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.0.1
I'm going to call this WONTFIX at this point, since we're moving to gmake on both windows and mac (mach-o).
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
verified wontfix.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: