If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Remove |MOZILLA_INTERNAL_API| from /suite/

RESOLVED FIXED in seamonkey2.10

Status

SeaMonkey
Build Config
--
trivial
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: sgautherie, Assigned: sgautherie)

Tracking

Trunk
seamonkey2.10
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

9 years ago
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...

Comment 2

9 years ago
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.

Comment 4

9 years ago
(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.
(Assignee)

Updated

9 years ago
Flags: in-testsuite-
Target Milestone: --- → seamonkey2.0alpha
(Assignee)

Comment 5

9 years ago
Created attachment 335227 [details] [diff] [review]
(Av1) 2 <Makefile.in>

[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)
(Assignee)

Comment 6

9 years ago
I filed bug 451917, bug 451918 and bug 451919 for the other apps.
Component: General → Build Config
QA Contact: general → build-config

Comment 7

9 years ago
(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
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 8

9 years ago
Whoops, clicked the wrong button there...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 9

9 years ago
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+
(Assignee)

Comment 10

9 years ago
Created attachment 335264 [details] [diff] [review]
(Av1a) </suite/app/Makefile.in>
[Superseded by bug 659205]

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)
(Assignee)

Updated

9 years ago
Status: REOPENED → ASSIGNED
Keywords: checkin-needed
Checked in, changeset: 181:ca22d2e44070
Keywords: checkin-needed

Comment 12

9 years ago
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

Comment 13

9 years ago
OK, I backed this out.

Comment 14

9 years ago
I noticed a debug non-tracemalloc build did succeed without the backout.  Might need to use a tracemalloc-enabled build to see the problem.
(Assignee)

Comment 15

9 years ago
[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.
(Assignee)

Updated

9 years ago
Depends on: 455095

Updated

9 years ago
Blocks: 451919
(Assignee)

Updated

9 years ago
Depends on: 483577
QA Contact: build-config → build-config

Comment 18

8 years ago
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.

Comment 20

8 years ago
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.
(Assignee)

Updated

8 years ago
Target Milestone: seamonkey2.0a1 → ---
(Assignee)

Updated

6 years ago
No longer blocks: 451919
(Assignee)

Updated

6 years ago
Attachment #335264 - Attachment description: (Av1a) </suite/app/Makefile.in> → (Av1a) </suite/app/Makefile.in> [Superseded by bug 659205]
Attachment #335264 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
No longer blocks: 397277
Severity: normal → trivial
Depends on: 659205, 397277
Target Milestone: --- → seamonkey2.10
(Assignee)

Comment 21

6 years ago
Created attachment 597255 [details] [diff] [review]
(Bv1) Remove obsolete BUILD_STATIC_SHELL (and MOZILLA_INTERNAL_API)
[Checked in: Comment 22]

Succeeded as
http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=b56b511812da
Attachment #597255 - Flags: review?(bugspam.Callek)

Updated

6 years ago
Attachment #597255 - Flags: review?(bugspam.Callek) → review+
(Assignee)

Comment 22

6 years ago
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]
(Assignee)

Updated

6 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.