Last Comment Bug 243169 - nsStaticComponent.h should be standalone friendly
: nsStaticComponent.h should be standalone friendly
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Doug Turner (:dougt)
:
Mentors:
Depends on:
Blocks: 205425
  Show dependency treegraph
 
Reported: 2004-05-10 03:36 PDT by Marco Pesenti Gritti
Modified: 2004-05-17 22:39 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
possible fix (5.45 KB, patch)
2004-05-13 12:28 PDT, Marco Pesenti Gritti
no flags Details | Diff | Splinter Review
fix missing stdio inclusion (6.05 KB, patch)
2004-05-15 02:13 PDT, Marco Pesenti Gritti
darin.moz: review+
doug.turner: superreview+
Details | Diff | Splinter Review
kill extra newline (6.04 KB, patch)
2004-05-17 11:58 PDT, Marco Pesenti Gritti
no flags Details | Diff | Splinter Review

Description Marco Pesenti Gritti 2004-05-10 03:36:58 PDT
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 2004-05-10 04:01:03 PDT
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 2004-05-13 12:28:43 PDT
Created attachment 148453 [details] [diff] [review]
possible fix
Comment 3 Marco Pesenti Gritti 2004-05-13 12:29:55 PDT
Comment on attachment 148453 [details] [diff] [review]
possible fix

Does something like this make sense?
Comment 4 Marco Pesenti Gritti 2004-05-15 02:13:37 PDT
Created attachment 148565 [details] [diff] [review]
fix missing stdio inclusion
Comment 5 Marco Pesenti Gritti 2004-05-15 02:20:20 PDT
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) 2004-05-15 22:41:10 PDT
Comment on attachment 148565 [details] [diff] [review]
fix missing stdio inclusion

looks fine.
Comment 7 Darin Fisher 2004-05-17 11:16:48 PDT
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 [:bsmedberg] 2004-05-17 11:45:40 PDT
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 2004-05-17 11:58:32 PDT
Created attachment 148684 [details] [diff] [review]
kill extra newline
Comment 10 Darin Fisher 2004-05-17 22:39:52 PDT
fixed-on-trunk

Note You need to log in before you can comment on or make changes to this bug.