Due to discussion in drivers@mo and the patch in bug 299988 which builds gtkmozembed only for MOZ_XUL_APP situations, this patch will build xulrunner with --disable-xul --disable-accessbility.

Can you share some of those discussions? Off-hand, it seems really odd to build something called xulrunner without support for xul.

This moves a couple of the toolkit/components/* pieces to be separate components for ease of ifdefing and maintenance. It also ifdefs the RDF-compat contents.rdf stuff from the toolkit chrome registry.

Please ignore the gtkmozembed bits of mozilla/Makefile.in which are from bug 299988.

Comment on attachment 208118 [details] [diff] [review] xulrunner with --disable-libxul, rev. 1 Does embedding/browser/gtk continue to build when building without XUL? Just confused about this change: +ifndef BUILD_STATIC_LIBS +ifdef MOZ_XUL_APP +ifneq (,$(MOZ_ENABLE_GTK)$(MOZ_ENABLE_GTK2)) +tier_50_dirs += embedding/browser/gtk +endif +endif +endif Your changes to mozilla/chrome seam to imply that it may be used without XUL. If this is true, then we may get rid of embedding/minimo/chromelite Is there any reason why you moved module defs out of nsToolkitCompsModule and into their own toolkit/components/* I will try to get a build going today to verify this all works. :-)

> Does embedding/browser/gtk continue to build when building without XUL? Yes, that was the whole point of this harebrained exercise... ;-) > Just confused about this change: > > +ifndef BUILD_STATIC_LIBS > +ifdef MOZ_XUL_APP > +ifneq (,$(MOZ_ENABLE_GTK)$(MOZ_ENABLE_GTK2)) > +tier_50_dirs += embedding/browser/gtk > +endif > +endif > +endif That's part of bug 299988, but what are you confused about? > Your changes to mozilla/chrome seam to imply that it may be used without XUL. > If this is true, then we may get rid of embedding/minimo/chromelite That's true. > Is there any reason why you moved module defs out of nsToolkitCompsModule and > into their own toolkit/components/* Ease of maintenance mainly: I'm trying to avoid the ifdef-hell which is xpfe/components/Makefile.in and xpfe/components/build[2].

does embedding/browser/gtk build if MOZ_XUL_APP isn't set?

No. That was the original issue we discussed in the drivers@ thread.

so, the point is, for those that were not on the thread, is to continue to be able to build embedding/browser/gtk with and without XUL. However that boils down to which and what #defines we use are the details.

btw... the patch looks good. I am going to test it out and r=.

Discussion summary that lead to this bug: http://benjamin.smedbergs.us/blog/2006-01-12/mozilla-embedding-small-devices-and-gtkmozembed/

benjamin, check it in. I will follow up with new bugs (and fixes) if need be.

Comment on attachment 208118 [details] [diff] [review] xulrunner with --disable-libxul, rev. 1 I'll take that as r=dougt ;-)

Fixed on trunk.

Comment on attachment 208118 [details] [diff] [review] xulrunner with --disable-libxul, rev. 1 I'd like this on 1.8 branch mainly to avoid lots of forkage with places work.

mac Firefox (imola) and Linux Seamonkey (luna) have been broken for over 9 hours now with no stars from anyone responsible for this patch. I can't get ahold of bsmedberg and dougt had no interest in fixing the bustage. I'm backing this out.

what a total mischaracterization of my position! Stuart, I am working on other things right now, I can't drop what I am doing. I suggested that you wait until the morning until benjamin can be found and has a bit of time to look at the bustage. I think this is totally reasonable because: 1) on the firefox tree imola is red, but imola is green 2) on the seamonkey tree, luna is red but lhasa is green.

Thanks Pav. It was frustrating not being able to build for several hours.

Turns out I tested this in a hacked-up static build: fixed issues include 1) use EXTRA_DSO_LDOPTS in the little components 2) combine toolkit/components/passwordmgr and toolkit/components/satchel into one mini-component instead of two, since satchel depends on passwordmgr symbols 3) Turned TestEmbed off on luna tbox since we no longer build gtkmozembed for seamonkey

My windows debug build is busted (clean build). It dies in toolkit/components/satchel/src like so: /cygdrive/c/builds/moz-trunk/mozilla/build/cygwin-wrapper link -NOLOGO -DLL -OUT:satchel.d ll -PDB:satchel.pdb -SUBSYSTEM:WINDOWS nsFormFillController.obj nsFormHistory.obj ./mod ule.res -DEBUG -DEBUGTYPE:CV -IMPLIB:fake.lib ../../../../dist/lib/passwordmgr_s. lib ../../../../dist/lib/unicharutil_s.lib ../../../../dist/lib/xpcom.lib ../../../../ dist/lib/xpcom_core.lib ../../../../dist/lib/nspr4.lib ../../../../dist/lib/plc4.lib ../.. /../../dist/lib/plds4.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi 32.lib Creating library fake.lib and object fake.exp nsFormFillController.obj : error LNK2019: unresolved external symbol "__declspec(dllimport ) public: __thiscall nsRect::nsRect(struct nsRect const &)" (__imp_??0nsRect@@QAE@ABU0@@Z) referenced in function "struct nsRect __cdecl GetScreenOrigin(class nsIDOMElement *)" (?G etScreenOrigin@@YA?AUnsRect@@PAVnsIDOMElement@@@Z) nsFormFillController.obj : error LNK2019: unresolved external symbol "__declspec(dllimport ) public: __thiscall nsRect::nsRect(int,int,int,int)" (__imp_??0nsRect@@QAE@HHHH@Z) refere nced in function "struct nsRect __cdecl GetScreenOrigin(class nsIDOMElement *)" (?GetScree nOrigin@@YA?AUnsRect@@PAVnsIDOMElement@@@Z) satchel.dll : fatal error LNK1120: 2 unresolved externals make[1]: *** [satchel.dll] Error 96 make[1]: Leaving directory `/cygdrive/c/builds/moz-trunk/ffox-debug-build/toolkit/componen ts/satchel/src' make: *** [all] Error 2 It looks to me like it should be linking against some GFX lib, but it is not. I suspect this patch is somehow to blame ;-)

Thank Stuart for finding and fixing the gkgfx linkage (windows dynamic debug builds only AFAICT)!