332400 - Correct misuse of ifdefs in the source tree.

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Mark Banner (:standard8)]

There are various ifdefs in the Mozilla source tree where the wrong one has been used. SeaMonkey needs them correcting in preparation for building it with
MOZ_XUL_APP=1.

Comment 1

[Mark Banner (:standard8)]

Attachment: Correct ifdef in directory/base/resources (checked in)

Two line patch to correct ifndef MOZ_XUL_APP to ifdef MOZ_SUITE in directory/base/resources/jar.mn. The ldap.properties file is only used within address book and Thunderbird has its own copy. Therefore this one is for suite even if suite is built as an xul app.

Comment 2

[Mark Banner (:standard8)]

Attachment: Remove incorrect ifndef in /themes (checked in)

Remove a incorrect ifndef in /themes/Makefile.in - The top-level makefile does this all for us with a ifndef MOZ_XUL_APP around the tier 50 and a ifdef MOZ_SUITE around tier 99.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

I remember thinking at one point that Thunderbird should _not_ have it's own copy of this, but it's possible that bsmedberg convinced me otherwise.  I'd be interested to hear his and mscott's thoughts on this...

Comment 4

[Robert Kaiser]

dmose:
Looks like the extra copy is already there, bsmedberg introduced that ifdef in bug 281988 to package this for suite only.
Mark just allows suite to still build it when it turns on MOZ_XUL_APP (which we're currently working on)...

Comment 5

[Benjamin Smedberg]

Comment on attachment 216898 [details] [diff] [review]
Correct ifdef in directory/base/resources (checked in)

The file got put in mail/locales because I needed it in a locales/* file for source-l10n and that was the available one at the time. I'm not sure whether it's worth creating directory/xpcom/locales just for this file.

Comment 6

[Robert Kaiser]

Benjamin, does this mean we should do an own copy of the file in suite/locales once SeaMonkey is moving to source L10n (which should be "soon")?
Does directory/ have enough locale strings that direcotry/locales would make sense?
From what I see, chrome://mozldap/ seems to be a separate chrome package at least, so maybe it might make sense after all?

Comment 7

[Robert Kaiser]

Attachment: fix browser and communicator chrome (checked in)

Those are simple fixes for building browser and communicator chrome even in the MOZ_XUL_APP case in suite, actually needed only as long as we don't have moved that stuff to suite/

Comment 8

[[e-mail]]

Comment on attachment 218808 [details] [diff] [review]
fix browser and communicator chrome (checked in)

>+#ifdef MOZ_SUITE
> comm.jar:
> *       content/navigator/contents.rdf                 (resources/content/contents.rdf)
> *       content/navigator-region/contents.rdf          (resources/content/contents-region.rdf)
Doesn't this need some of those % lines that (e.g.) communicator has?

Comment 9

[Robert Kaiser]

(In reply to comment #8)
> Doesn't this need some of those % lines that (e.g.) communicator has?

Those are no must from what I was told, the new chrome registry still does understand the contents.rdf files. We should move to the new %-lines for chrome registration along with the move of the files to suite/ but for now, we can live with still using contents.rdf for those.

Comment 10

[Robert Kaiser]

Comment on attachment 218808 [details] [diff] [review]
fix browser and communicator chrome (checked in)

Checked in that patch, thanks.

Comment 11

[Robert Kaiser]

Attachment: fix xpfe/components/jar.mn (checked in)

This makes suite build permissions etc. again in any case, even in suiterunner configuration.

Comment 12

[Robert Kaiser]

Comment on attachment 219146 [details] [diff] [review]
fix xpfe/components/jar.mn (checked in)

Checked in that one-liner as well :)

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Could https://bugzilla.mozilla.org/attachment.cgi?id=219146 have caused bug 334899?

Comment 14

[Robert Kaiser]

Attachment: fix editor/ui

editor/ui excludes locale files with another of those ifdefs. This patch fixes that and also adds the overlays that were still missing for suite.

Comment 15

[[e-mail]]

Comment on attachment 219291 [details] [diff] [review]
fix editor/ui

Nit: would be nice to add an #ifdef for % locale editor-region etc.

Comment 16

[Robert Kaiser]

Attachment: fix editor/ui, v2 - including -region (checked in)

This version also includes the corrected -region registration so that editor realls starts up in suiterunner.

Comment 17

[Robert Kaiser]

Comment on attachment 219307 [details] [diff] [review]
fix editor/ui, v2 - including -region (checked in)

Checked in, r+sr=Neil via IRC on the additional changes to first version.

Comment 18

[Mark Mentovai]

Comment on attachment 218808 [details] [diff] [review]
fix browser and communicator chrome (checked in)

The change to xpfe/browser/jar.mn eliminated navigator/locale/navigator.propertie. from Camino's embed.jar, causing Camino bug 335026.  I'll fix that by eliminating the reliance on embed.jar for the UA language (bug 334756) but I wanted to note the problem here in case other similar things crop up.

Comment 19

[Mark Mentovai]

(In reply to comment #18)
Actually, we'll still try to use general.useragent.locale from embed.jar as a fallback when we can't get the locale through other means...

Comment 20

[Robert Kaiser]

(In reply to comment #18)
> The change to xpfe/browser/jar.mn eliminated
> navigator/locale/navigator.propertie. from Camino's embed.jar, causing Camino
> bug 335026.

I was told to not care about Camino, so I didn't. I just hope both Camino and us dropping xpfe/ is near, so that we're not able to run into such traps again. Die, embed.jar! ;-)

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 216898 [details] [diff] [review]
Correct ifdef in directory/base/resources (checked in)

r+sr=dmose; sorry for the delay.

Comment 22

[Mark Banner (:standard8)]

I think I've been through all the remaining MOZ_XUL_APP definitions and haven't found anymore that we need. Therefore I'll mark this as fixed. If we do, then we can always reopen or deal with in another bug.