243169 - nsStaticComponent.h should be standalone friendly

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Marco Pesenti Gritti]

Right now it cause the inclusion of nsString:

nsStaticComponent.h -> nsComponentLoader.h -> nsHashtable.h -> nsString.h

So it's not possible to do a static build of code using nsEmbedString.
We seem to only need the nsGetModuleProc definition from nsComponentLoader.h.
Maybe it would be possible to move it in another file ?

Comment 1

[Marco Pesenti Gritti]

More precisely the problem is that you cant include nsStaticComponent.h and use
embed string in the same file. It would be probably possible to work around the
problem in gtkmozembed using a separate file or something, though I think it
would be much more convenient to cleanup these headers if possible.

Comment 2

[Marco Pesenti Gritti]

Attachment: possible fix

Comment 3

[Marco Pesenti Gritti]

Comment on attachment 148453 [details] [diff] [review]
possible fix

Does something like this make sense?

Comment 4

[Marco Pesenti Gritti]

Attachment: fix missing stdio inclusion

Comment 5

[Marco Pesenti Gritti]

Comment on attachment 148565 [details] [diff] [review]
fix missing stdio inclusion

For gtkmozembed the alternative is to add an Init function to
EmbedComponents.cpp (there embed strings are not included) and do
NSGetStaticModuleInfo = gtk_getModuleInfo; in it instead of in
EmbedPrivate.cpp.
Not sure what I like better, I guess it depend if we expect to hit the same
problem somewhere else in the future. Up to you.

Comment 6

[Doug Turner (:dougt)]

Comment on attachment 148565 [details] [diff] [review]
fix missing stdio inclusion

looks fine.

Comment 7

[Darin Fisher]

Comment on attachment 148565 [details] [diff] [review]
fix missing stdio inclusion

r=darin

kill extra newline at the end of nsModule.h

shouldn't we put @status FROZEN in this file?  and shouldn't it be exported to
the SDK?  (add to SDK_HEADERS in the Makefile?)

or is there some reason not to include this in the gecko sdk?

Comment 8

[Benjamin Smedberg]

I don't think that the current static component loader is sufficiently settled
to freeze it.

In particular, we're probably going to need to support multi-tier static
components (from libxul and client apps).

Comment 9

[Marco Pesenti Gritti]

Attachment: kill extra newline

Comment 10

[Darin Fisher]

fixed-on-trunk