Closed
Bug 535342
Opened 15 years ago
Closed 15 years ago
Fix dependentlibs.list packaging in SeaMonkey
Categories
(SeaMonkey :: Build Config, defect)
SeaMonkey
Build Config
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey2.1a1
People
(Reporter: sgautherie, Assigned: sgautherie)
References
Details
(Whiteboard: [fixed by bug 521523])
http://mxr.mozilla.org/mozilla/search?string=dependentlibs.list&case=on http://mxr.mozilla.org/mozilla1.9.1/search?string=dependentlibs.list&case=on (I would have to check if FF 3.0/3.5 actually packaged this file or not...) http://mxr.mozilla.org/mozilla1.9.2/search?string=dependentlibs.list&case=on http://mxr.mozilla.org/comm-central/search?string=dependentlibs.list&case=on FF 3.6+ seems to want to remove it only. Yet SeaMonkey 2.0/2.1 reports: { 'make package-compare' [...] +bin/dependentlibs.list } Then I'm puzzled at what the correct fix would be: *Should SM package the available file?? *Should SM (or Core) not create this file in the first place!? *...
Flags: in-testsuite-
Comment 1•15 years ago
|
||
I have this incorporated into my patch for bug 521523 at the moment. I don't see what you mean with "FF 3.6 seems to want to remove it only", in fact I see it being packaged in http://mxr.mozilla.org/comm-central/source/mozilla/browser/installer/package-manifest.in#43
Depends on: 521523
Comment 2•15 years ago
|
||
Should be fixed by bug 521523 now.
Assignee | ||
Comment 3•15 years ago
|
||
(In reply to comment #1) > I have this incorporated into my patch for bug 521523 at the moment. Indeed. c-c: fixed. c-c wrt m-1.9.2: fixed, ahead of FF3.6. c-1.9.1: probably still needs fixing (here)... > I don't see what you mean with "FF 3.6 seems to want to remove it only", I understand your comment: see bug 542004 which landed in the meantime(!) ;-> Per discussion there, shouldn't SM use an "#ifdef MOZ_LIBXUL" or the like? (even if that means getting this file back in the report ftb :-/) And we should probably remove this file when "#ifndef MOZ_LIBXUL" too, no?
Whiteboard: [fixed by bug 521523]
Comment 4•15 years ago
|
||
(In reply to comment #3) > I understand your comment: see bug 542004 which landed in the meantime(!) ;-> > > Per discussion there, shouldn't SM use an "#ifdef MOZ_LIBXUL" or the like? We should test carefully and see if there are problems with having this file in our builds even though we're not libxul-based. If there actually is no problem, we can just leave it as-is.
You need to log in
before you can comment on or make changes to this bug.
Description
•