Closed Bug 243169 Opened 20 years ago Closed 20 years ago

nsStaticComponent.h should be standalone friendly


(Core :: XPCOM, defect)

Not set





(Reporter: mpgritti, Assigned: dougt)




(1 file, 2 obsolete files)

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 ?
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.
Attached patch possible fix (obsolete) — Splinter Review
Comment on attachment 148453 [details] [diff] [review]
possible fix

Does something like this make sense?
Attachment #148453 - Flags: review?(dougt)
Attachment #148453 - Flags: review?(dougt)
Attached patch fix missing stdio inclusion (obsolete) — Splinter Review
Attachment #148453 - Attachment is obsolete: true
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
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.
Attachment #148565 - Flags: superreview?(dougt)
Attachment #148565 - Flags: review?(darin)
Comment on attachment 148565 [details] [diff] [review]
fix missing stdio inclusion

looks fine.
Attachment #148565 - Flags: superreview?(dougt) → superreview+
Comment on attachment 148565 [details] [diff] [review]
fix missing stdio inclusion


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?
Attachment #148565 - Flags: review?(darin) → review+
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).
Attachment #148565 - Attachment is obsolete: true
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.