Closed Bug 451871 Opened 11 years ago Closed 8 years ago

Remove |MOZILLA_INTERNAL_API| from /suite/

Categories

(SeaMonkey :: Build Config, defect, trivial)

defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.10

People

(Reporter: sgautherie, Assigned: sgautherie)

References

()

Details

Attachments

(1 file, 2 obsolete files)

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.
Flags: in-testsuite-
Target Milestone: --- → seamonkey2.0alpha
Attached patch (Av1) 2 <Makefile.in> (obsolete) — Splinter Review
[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
]
Assignee: general → sgautherie.bz
Status: NEW → ASSIGNED
Attachment #335227 - Flags: superreview?(bienvenu)
Attachment #335227 - Flags: review?(neil)
I filed bug 451917, bug 451918 and bug 451919 for the other apps.
Component: General → Build Config
QA Contact: general → build-config
(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.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whoops, clicked the wrong button there...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Attachment #335227 - Flags: review?(neil) → review+
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 :->
Attachment #335227 - Attachment is obsolete: true
Attachment #335227 - Flags: superreview?(bienvenu)
Status: REOPENED → ASSIGNED
Keywords: checkin-needed
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.
Depends on: 455095
Blocks: 451919
Depends on: 483577
QA Contact: build-config → build-config
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.
Target Milestone: seamonkey2.0a1 → ---
No longer blocks: 451919
Attachment #335264 - Attachment description: (Av1a) </suite/app/Makefile.in> → (Av1a) </suite/app/Makefile.in> [Superseded by bug 659205]
Attachment #335264 - Attachment is obsolete: true
No longer blocks: 397277
Severity: normal → trivial
Depends on: 659205, 397277
Target Milestone: --- → seamonkey2.10
Attachment #597255 - Flags: review?(bugspam.Callek) → review+
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
Attachment #597255 - Attachment description: (Bv1) Remove obsolete BUILD_STATIC_SHELL (and MOZILLA_INTERNAL_API) → (Bv1) Remove obsolete BUILD_STATIC_SHELL (and MOZILLA_INTERNAL_API) [Checked in: Comment 22]
Status: ASSIGNED → RESOLVED
Closed: 11 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.