535342 - Fix dependentlibs.list packaging in SeaMonkey

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Serge Gautherie (:sgautherie)]

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]

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]

Should be fixed by bug 521523 now.

Comment 3

[Serge Gautherie (:sgautherie)]

(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]

(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.