286729 - libXUL step 4 - rest of toolkit

Status: RESOLVED FIXED

(Toolkit Graveyard :: Build Config, defect)

Description

[Benjamin Smedberg]

This incorporates pretty much all of the rest of toolkit into libxul. I've
discovered some interesting/awful build dependencies here that I will fix later.

Comment 1

[Benjamin Smedberg]

Attachment: libxul, step 4, revision 1

Please ignore the UI changes in xpfe/components/console and
toolkit/componnets/console, they are for another bug.

Comment 2

[Darin Fisher]

Comment on attachment 177867 [details] [diff] [review]
libxul, step 4, revision 1

So xul.dll now contains nsAppRunner.cpp?  (sounds good)  And xulrunner.exe has
its own copy of nsINIParser.cpp :-/  And, you are for the first time making
XUL.dll be something people may directly link against?	Seems like some big
changes happening here.

Comment 3

[Benjamin Smedberg]

> So xul.dll now contains nsAppRunner.cpp?  (sounds good)

Yes.

>  And xulrunner.exe has
> its own copy of nsINIParser.cpp :-/

Yes.

> And, you are for the first time making
> XUL.dll be something people may directly link against?

Define "people"... xulrunner.exe links against it, but it already does, so it's
not a revolutionary change. It's true that this is the first time we're
exporting XRE_main, but so what? I do intend to freeze it for 1.9, if not before.

Comment 4

[Darin Fisher]

My point was that this is us moving toward having end consumers link against
xul.dll as well as xpcom.dll to embed us.  I think that's fine, and I think
we've talked about doing that, but perhaps you should update the libxul wiki to
talk about this.

Comment 5

[Darin Fisher]

Comment on attachment 177867 [details] [diff] [review]
libxul, step 4, revision 1

>Index: Makefile.in

>+ifdef MOZ_ENABLE_LIBXUL
>+tier_50_dirs += \
>+		toolkit/library \
>+		xpcom/stub \
>+		$(NULL)
>+endif
>+
>+ifdef MOZ_PSM
>+tier_50_dirs	+= security/manager
>+endif

Eventually, we'll want to fold PSM into LibXUL.  NSS itself should
probably remain standalone since it installed as a system library
on some linux distros already.


>Index: chrome/Makefile.in

>-DIRS		= public src tools
>+DIRS = public src
>+
>+TOOL_DIRS = tools

I kind of like the indented variable values myself, but no biggy.


>Index: toolkit/profile/src/nsToolkitProfileService.cpp

>+extern "C" XULAPI nsresult
>+XRE_GetFileFromPath(const char *aPath, nsILocalFile* *aResult)

nit: when implementing these methods there's no need to include the
|extern "C" XULAPI| prefix provided you #include the header file
where they are declared.  It shouldn't matter, but in xpcom that's
the convention we use.


>Index: toolkit/xre/nsXULAppAPI.h

>+#ifdef MOZ_ENABLE_LIBXUL
>+#ifdef IMPL_XULAPI
>+#define XULAPI NS_EXPORT
>+#else
>+#define XULAPI NS_IMPORT
>+#endif
>+#else
>+#define XULAPI
>+#endif

So, consumers will need to #define MOZ_ENABLE_LIBXUL if they wish
to import these functions, right?  Hmm... we might change that in
the future to make it the default.


r=darin

Comment 6

[Benjamin Smedberg]

This was checked in last Friday.