Last Comment Bug 535342 - Fix dependentlibs.list packaging in SeaMonkey
: Fix dependentlibs.list packaging in SeaMonkey
Status: RESOLVED FIXED
[fixed by bug 521523]
:
Product: SeaMonkey
Classification: Client Software
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: seamonkey2.1a1
Assigned To: Serge Gautherie (:sgautherie)
:
:
Mentors:
Depends on: 298044 521523 542004
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-16 12:03 PST by Serge Gautherie (:sgautherie)
Modified: 2010-02-11 04:26 PST (History)
2 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Serge Gautherie (:sgautherie) 2009-12-16 12:03:18 PST
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!?
*...
Comment 1 Robert Kaiser 2010-01-31 04:49:57 PST
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
Comment 2 Robert Kaiser 2010-02-06 09:35:55 PST
Should be fixed by bug 521523 now.
Comment 3 Serge Gautherie (:sgautherie) 2010-02-11 01:05:17 PST
(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?
Comment 4 Robert Kaiser 2010-02-11 04:26:06 PST
(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.

Note You need to log in before you can comment on or make changes to this bug.