210791 - --disable-xpfe-components doesn't work with componentlib or static build

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, defect)

Description

[Conrad Carlen (not reading bugmail)]

Using the --disable-xpfe-components in a componentlib build, I got link errors
in linking the component lib. Here's why: final-link-comps is built up during
the export phase: http://lxr.mozilla.org/seamonkey/source/config/rules.mk#629.
But, because of this:
http://lxr.mozilla.org/seamonkey/source/xpfe/Makefile.in#35, we end up doing the
export on this anyway and thus adding xpfe comps to final-link-comps. D'oh!

The best thing would be to get rid of the evil deps mentioned in dougt's
comments so we don't have to export these headers even when not building xpfe
comps. Though, since final-link-comps needs to represent only what was actually
built, could that be done on the libs phase instead of export?

Comment 1

[Alec Flett]

which comments from dougt? its possible that some of these dependencies are gone
- I recently fixed the bookmarks dependency that layout has. Furthermore,
nsIGlobalHistory.idl really should be moved to docshell/base

Comment 2

[Conrad Carlen (not reading bugmail)]

which comments: http://lxr.mozilla.org/seamonkey/source/xpfe/Makefile.in#35.
According to cvs blame, they're dougt's.

BTW, in a branch I'm using which is very close to 1.4, the deps are gone. I
removed the bit which forced an export in components, removed dist, built, and
it was fine. I'll try that with the trunk next.

Comment 3

[Conrad Carlen (not reading bugmail)]

mailnews/addrbook/public/nsIAbAutoCompleteSession.idl depends upon
xpfe/components/autocomplete/public/nsIAutoCompleteSession.idl

Building mailnews without xpfe-components is probably not a desired config (?)

Comment 4

[Conrad Carlen (not reading bugmail)]

Current list of deps (assuming mailnews isn't built)

dom/src/base/nsGlobalWindow.h:81:24: nsISidebar.h: No such file or directory.
docshell/base/nsDocShell.h:63:30: nsIGlobalHistory.h: No such file or directory
docshell/base/nsDocShell.cpp:131:31: nsIBrowserHistory.h: No such file or directory
xpfe/browser/src/nsBrowserInstance.cpp:116:25: nsITimeBomb.h: No such file or
directory
extensions/typeaheadfind/src/nsTypeAheadFind.h:54:28: nsIFindService.h: No such
file or directory

Comment 5

[Alec Flett]

oh man, no! yeah, I think --disable-xpfe-components should imply
--disable-mailnews or something. I'm sure there are lots of similar dependencies
even if we managed to solve that one.

as for the rest:
- nsGlobalWindow/nsISidebar - there' a bug reported by [e-mail]
about that one, if someone wants to search for it. I'm not quite sure what to
do. really, the sidebar should be attached to the window object dynamically -
maybe jst can help us out there.
- nsIGlobalHistory.idl should be moved do docshell/base
- xpfe/browser should probably be disabled as well - I doubt there are any
non-JS consumers of nsIBrowserInstance
- we've talked about moving nsIFindService somewhere else, like embedding/
somewhere. 

Comment 6

[Conrad Carlen (not reading bugmail)]

Yeah, though those deps need to be broken, I need a solution to this soon. As
in: would it be possible to build up final-link-comps on the libs target instead
of the export target? See the lxr link to rules.mk. seawood?

Comment 7

[hacker formerly known as [e-mail]]

Possible, yes.  You would run into the risk of (silently) failing to get all of
your desired functionality if someone attempted to use final-link-libs before
all of the libs were built though. 

Having configure options implicitly disable other unrelated configure options is
lame.  If you're not going to fix the dependency, you should add a test and stop
configure with an explanation rather than letting developers wonder what
happened to mailnews when they tried to disable some unneeded xpfe functionality.

Comment 8

[cls]

*** Bug 214940 has been marked as a duplicate of this bug. ***

Comment 9

[David G King]

While this may primarily be a mailnews problem, I see it on my attempt to build
a static version of Sunbird (calender) Win32 and cygwin/mingw.

Comment 10

[Stephen Walker]

*** Bug 238983 has been marked as a duplicate of this bug. ***

Comment 11

[g. fischer]

hello,

all useless cause i did not use --disable-xpfe-components!
somebody got a good solution?

Comment 12

[David G King]

A possible workaround can be found in Bug #214940
http://bugzilla.mozilla.org/show_bug.cgi?id=214940#c5

Comment 13

[Robert Kaiser]

I think SeaMonkey doesn't care about --disable-xpfe-components any more, so WONTFIXing this one.