24515 - Cant build XPCOM standalone

Status: RESOLVED INVALID

(Core :: XPCOM, defect, P3)

Description

[Suresh Duddi (gone)]

Obstacles to xpcom standalone are header dependencies from xpcom to intl for
charset converters. These need to be removed and a standalone target made to
build xpcom.

Comment 1

[cls]

I ran across another dependency, xpcom/base/nsTraceRefcnt.cpp includes nsIPref.h
which means xpcom also requires libpref's (header) dependencies as well.  

Aside from dependencies, is there any particular method you wanted to use for a
standalone xpcom?  Did you want to use Makefile.ref's like js does or have your
own standalone configure setup like xmlterm has?

Comment 2

[Suresh Duddi (gone)]

Just removed the pref dependency. Now for the intl stuff.

Comment 3

[Suresh Duddi (gone)]

Just removed the pref dependency. Now for the intl stuff.

Comment 4

[Suresh Duddi (gone)]

*** Bug 24535 has been marked as a duplicate of this bug. ***

Comment 5

[cls]

xpcom/proxy/src/nsProxyObjectManager.cpp appears to depend upon nsAppShellCIDs.h
but if I comment out that include, it compiles fine.

Here's the list of directories that are required to be traversed to build xpcom
standalone:
$(NSPRPUB_DIR) modules/libreg xpcom intl/unicharutil/public intl/uconv/public

This does not include xpcom/tests though. If you want to build that, then you
need to build libtimer and libmozjs which each bring in a whole other set of
dependencies.

Comment 6

[cls]

Like I noted in the related dbm bug, I just added the --enable-modules build
option to configure.  Currently, it only works with dbm & xpcom and still
requires you to pull the entire tree but we're working to fix that.  Per the
previous comment, the standalone xpcom build does not build tests.

Comment 7

[cls]

Attachment: Remove unneeded dependency upon nsAppShellCIDs.h

Comment 8

[cls]

The previous patch has been checked in (r=shaver).  Any word on cleaning up
xpcom/tests ?

Comment 9

[Suresh Duddi (gone)]

It would be nice if we can build xpcom standalone.

Comment 10

[cls]

I get this error when I remove <nsIPref.h> from
xpcom/reflect/xptinfo/src/xptiprivate.h .

../../../../../mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp:
In method `xptiInterfaceInfoManager::xptiInterfaceInfoManager()':
../../../../../mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp:92:
`nsIPref' undeclared (first use this function)

Um, we're using prefs for logging stats?  After commenting out the body of 
xptiInterfaceInfoManager::xptiInterfaceInfoManager() in
xptiInterfaceInfoManager.cpp, the dependency is gone.

xptiprivate.h also includes nsIZipReader.h which pulls in a dependency upon
libjar and thus, caps & psm-glue.  Not being familiar with the code, I don't see
a quick fix for this one. 

Comment 11

[cls]

Attachment: Patch to bring the --enable-modules model in sync with the --enable-xpcom-standalone setup. (Removes--enable-xpcom-standalone)

Comment 12

[Suresh Duddi (gone)]

Thanks Chris. I will try this tonight and do the change.

Comment 13

[cls]

Are we planning to stick with the XPCOM_STANDALONE define or are there plans to
eventually make a standalone xpcom use the same config as the in-browser one?
CCing the resident Mac gurus as a cry for help in getting this working on the
Mac.

Comment 14

[Ray Whitmer]

Too make design problems in XPCOM ahead of this one.  Making future.

Comment 15

[Brendan Eich [:brendan]]

Is this up for grabs?  cls, you want to take it?

/be

Comment 16

[cls]

I'm not qualified to make design decisions about xpcom.  I can probably make the
current standalone setup work under win32 & mac but it'll just take us further
into #ifdef hell.

Comment 17

[cls]

*** Bug 57016 has been marked as a duplicate of this bug. ***

Comment 18

[cls]

[e-mail] wrote the following in bug 57016:

I am building a embedding target which uses the BUILD_MODULE macro.  This (for
whatever reason) defines xpcom to be 'standalone'.  In standalone, xpcom does
not include the implementation of the nsUnicharInputStream.  Why this is, I can
not tell.  Layout requires this to be present.  So, after I am doing building, I
exit because layout can not find these needed implmentation.

dp added this the #ifndef here:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpcom/io&command=DIFF_FRAMESET&file=nsUnicharInputStream.cpp&rev2=3.23&rev1=3.22
 In my build, I have taken this out and can still build standalone without any
trouble.

Any ideas about this?  Can I remove this #ifndef safely?  Or should I try to fix
layout not to use this implementation.  Here are the callers:

http://lxr.mozilla.org/seamonkey/search?string=NS_NewConverterStream

Comment 19

[cls]

But you're not really building xpcom standalone.  You have the additional
embedding requirements.  I'm going to venture that removing the ifdef works for
you because you use the intl/ in other parts of the embedding code. Remove the
ifdefs and then try building just xpcom standalone.

Comment 20

[Doug Turner (:dougt)]

Okay.  I understand.  So, how come we enabled XPCOM Standalone if we use the
BUILD_MODULE macros by default?  

Comment 21

[cls]

Because no one had a pressing need for the alternative?  The XPCOM_STANDALONE
define works for the xpconnect standalone case as well which is really the only
other standalone module that's currently setup to use xpcom.

Comment 22

[Doug Turner (:dougt)]

right.

I need to be able to build just some subset of the "seamonkey" project.  You
suggested that I use BUILD_MODULE_DIRS.  Now, this enables STANDALONE for xpcom
and xpconnect.  Can we remove this implict define and make people building
standalone pass that to configure like it was before?

Thanks

Comment 23

[cls]

I suggested using BUILD_MODULE as an alternative to creating a special target
for embedding in the Makefiles because the arch was already inplace.  People
have never passed the STANDLONE defines to configure.  They have only existed as
long as the enable-modules / xpcom-standalone modules have existed.

The proper fix for this is to fix xpcom so that its standalone case doesn't
require the extra defines.  But no one seems to have the desire/time/ability to
remove intl & prefs from xpcom for the default build.  To continue with the
hack, modify config/config.mk so that the standalone defines only get set if
BUILD_MODULES is set to xpcom or xpconnect but don't break our existing
standalone setup.

Comment 24

[Brendan Eich [:brendan]]

Do we have a bug on file against xpcom for its bogus intl and prefs
dependencies?

/be

Comment 25

[Warren Harris]

I don't recall seeing a bug for that.

Comment 26

[cls]

umm, this is it.

Comment 27

[Brendan Eich [:brendan]]

Ok, this is the bug, but it seems misassigned.  I submit that rayw is unlikely
to relieve xpcom of bogus intl and prefs deps.  Who will do it?  Scc?  Shaver? 
Warren?  Jband?

/be

Comment 28

[Warren Harris]

Assigning rest of xpcom stuff to myself (from Ray).

Comment 29

[cls]

The standalone build structure was changed (see bug 57282) to accommodate the
fact that people want the best of both worlds, building fully functional modules
but without buliding the entire tree.  I believe that change should remove the
need for the XPCOM_STANDALONE defines on unix.  Would someone care to verify
this?

Comment 30

[Dawn Endico]

dp is no longer @netscape.com. changing qa contact to default for this product

Comment 31

[Asa Dotzler [:asa]]

reasigning warren bugs to default component owners.

Comment 32

[Doug Turner (:dougt)]

reassign all kandrot xpcom bug.

Comment 33

[Doug Turner (:dougt)]

this is going to be fixed by alecf work such that there will not be a need for
the standalone xpcom targe.