http://mxr.mozilla.org/comm-central/source/suite/app/Makefile.in#96 [ 93 ifdef MOZ_ENABLE_LIBXUL 94 APP_XPCOM_LIBS = $(XPCOM_GLUE_LDOPTS) 95 else 96 MOZILLA_INTERNAL_API = 1 97 APP_XPCOM_LIBS = $(XPCOM_LIBS) 98 endif ] *** Per bug 450781 comment 16: [ neil@parkwaycc.co.uk 2008-08-23 09:51:37 PDT it looks like suite still has some internal API e.g. nsISupportsArray. ]

As I pointed out in bug 450781 comment 17: However unless you want type-unsafety in the code that uses it, then you need to either remove nsISupportsArray from the RDF code, or remove the RDF code from the bookmark code. So I think you want the title of this bug to be "remove nsISupportsArray from RDF" or "remove bookmark usage of RDF" depending on what Neil prefers...

I don't know much about suite/app - maybe it really needs to be compiled differently depending on whether MOZ_ENABLE_LIBXUL is set or not. The internal API I was referring to is best covered by bug 397277.

Oh opps, I missed this was suite/app/Makefile.in. So MOZILLA_INTERNAL_API there is essentially if you're not building with MOZ_ENABLE_LIBXUL. So if you can still build a standard SeaMonkey successfully without it, then yes we can drop it, if you can't you may as well close this bug and just have a general post-libxul tidy up bug (and there's no point in filing that yet) - as you won't be able to drop it until post transfer to libxul.

(In reply to comment #3) > So MOZILLA_INTERNAL_API there is essentially if you're not building with > MOZ_ENABLE_LIBXUL. So if you can still build a standard SeaMonkey successfully > without it, then yes we can drop it It appears to build without MOZILLA_INTERNAL_API if you use XPCOM_GLUE_LDOPTS.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/20080824061952 SeaMonkey/2.0a1pre] (home, optim default) (W2Ksp4) The /suite/ part is enough to compile an optim build. *** [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/20080824054832 SeaMonkey/2.0a1pre] (home, debug default) (W2Ksp4) The additional /mailnews/ part is needed to compile a debug build. (Through I did not try to find out why.) The error I was getting: [ nsMimeModule.cpp ...\mozilla\dist\include\msgbase\nsIMsgHdr.h(14) : fatal error C1083: Cannot open include file: 'MailNewsTypes2.h': No such file or directory ]

I filed bug 451917, bug 451918 and bug 451919 for the other apps.

(In reply to comment #5) > The additional /mailnews/ part is needed to compile a debug build. > (Through I did not try to find out why.) Probably because opt builds default to static mail which doesn't use this file.

Whoops, clicked the wrong button there...

Comment on attachment 335227 [details] [diff] [review] (Av1) 2 <Makefile.in> I'd be surprised if a separate bug hasn't been filed on the debug mailnews bustage.

Av1, /suite/ part only. (In reply to comment #9) > I'd be surprised if a separate bug hasn't been filed on the debug mailnews > bustage. Indeed, (in the meantime), bug 451903 :->

Checked in, changeset: 181:ca22d2e44070

This hosed nye as well as my local build: ###!!! ASSERTION: nsTHashtable::Init() should not be called twice.: 'Error', file ../../dist/include/xpcom/nsTHashtable.h, line 327 ###!!! ASSERTION: nsDirectoryService::RealInit Mustn't initialize twice!: '!gService', file /build/andrew/seamonkeyc/src/mozilla/xpcom/io/nsDirectoryService.cpp, line 506 *** Registering components in: nsPrefModule ... it continues until it goes to register nsSuiteGlue, at which point it all falls apart. http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1219611600.1219612074.2748.gz&fulltext=1

OK, I backed this out.

I noticed a debug non-tracemalloc build did succeed without the backout. Might need to use a tracemalloc-enabled build to see the problem.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080830193845 SeaMonkey/2.0a1pre] (home, debug default) (W2Ksp4) With trace-malloc (compiled (and activated)) and this patch, but non-libxul, my (clobber) Windows build runs fine (but real slow, as expected): ... *** Registering components in: nsSoftwareUpdate *** Registering components in: nsPrefModule ... ***** [ .../seamonkey-bin -register ] Though I don't know what this option is... (not listed in -help) Could someone else check this on Linux (or MacOSX) ?

seamonkey-bin is the Unix/Linux form of what is called seamonkey.exe on Windows and (IIUC) seamonkey.app on the Mac. IOW if you build a file by that name in a supposedly "Win32" context there's something fishy happening. -register I don't know (and don't have it in -help on Linux). Maybe "make yourself the default browser"? Or else, something with rebuilding SeaMonkey's own lists of components etc.? Your guess is as good as mine.

-register is to force the component registration process without starting the application.

Does this block bug 394502 (moving to libxul)?

Strictly speaking, I don't think it does, because the MOZILLA_INTERNAL_API is wrapped in a MOZ_ENABLE_LIBXUL ifdef. It would just be nice not to have it.

This bug is open but targeted for seamonkey2.0a1, which has been released a long time ago. Please set the target milestone to an appropriate value, "---" if it has no specific target.

Succeeded as http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=b56b511812da

Comment on attachment 597255 [details] [diff] [review] (Bv1) Remove obsolete BUILD_STATIC_SHELL (and MOZILLA_INTERNAL_API) [Checked in: Comment 22] http://hg.mozilla.org/comm-central/rev/7b77535fca53