1224059 - mozbuild.preprocessor.Error: suite/locales/jar.mn : 'UNDEFINED_VAR', 'LOCALE_SRCDIR'

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Edmund Wong (:ewong)]

Current bustage:

js/src/ctypes/libffi> config.status: executing depfiles commands
js/src/ctypes/libffi> config.status: executing libtool commands
js/src/ctypes/libffi> config.status: executing include commands
js/src/ctypes/libffi> config.status: executing src commands

Reticulating splines...
Traceback (most recent call last):
  File "./config.status", line 1072, in <module>
    config_status(**args)
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/config_status.py", line 178, in config_status
    the_backend.consume(definitions)
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/backend/base.py", line 120, in consume
    if not self.consume_object(obj):
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/backend/fastermake.py", line 88, in consume_object
    self._consume_jar_manifest(obj, defines)
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/backend/fastermake.py", line 209, in _consume_jar_manifest
    pp.do_include(obj.path)
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/preprocessor.py", line 772, in do_include
    self.handleLine(l)
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/preprocessor.py", line 546, in handleLine
    cmd(args)
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/preprocessor.py", line 781, in do_includesubst
    args = self.filter_substitution(args)
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/preprocessor.py", line 728, in filter_substitution
    return self.varsubst.sub(repl, aLine)
  File "/builds/slave/c-cen-t-lnx/build/mozilla/python/mozbuild/mozbuild/preprocessor.py", line 726, in repl
    raise Preprocessor.Error(self, 'UNDEFINED_VAR', varname)
mozbuild.preprocessor.Error: ('/builds/slave/c-cen-t-lnx/build/suite/locales/jar.mn', 376, 'UNDEFINED_VAR', 'LOCALE_SRCDIR')
*** Fix above errors and then restart with\
               "make -f client.mk build"
make[1]: *** [configure] Error 1
make[1]: Leaving directory `/builds/slave/c-cen-t-lnx/build'
make: *** [/builds/slave/c-cen-t-lnx/build/objdir/Makefile] Error 2

Comment 1

[Edmund Wong (:ewong)]

Last good csets:
  c-c : 1d7535f9bc102939d4c43523e9bb6f870fcfe1d5
  m-c : 754119dfb99f38f344fdfc316654ee66ee889801

First Bad cset:
  c-c : 1d7535f9bc102939d4c43523e9bb6f870fcfe1d5
  m-c : 84a7cf29f4f14c9b359db2f7f19c0abd6a8e178e

Comment 2

[Edmund Wong (:ewong)]

While it wasn't directly caused by http://hg.mozilla.org/mozilla-central/rev/52f3219b0a79, 
it brought the issue to light, in that the preprocessor as called by
fastermake.py doesn't like LOCALE_SRCDIR because at that point, it doesn't
know anything about it.

From :glandium, it seems having an extra jar.mn from the locale isn't
a good idea.  Neil, any ideas?

Comment 3

[Edmund Wong (:ewong)]

Attachment: [option 1] Change LOCALE_SRCDIR to AB_CD (v1)

Comment 4

[Edmund Wong (:ewong)]

Attachment: [option 2] Remove the includesubst line.

Comment 5

[Edmund Wong (:ewong)]

Another option is to actually define the LOCALE_SRCDIR in moz.build;
but I don't know what the LOCALE_SRCDIR is.

Comment 6

[[e-mail]]

LOCALE_SRCDIR already exists, but I guess it's now only a Makefile variable, so you have to manually add it to the defines that the jar builder users, using DEFINES += -DLOCALE_SRCDIR=$(LOCALE_SRCDIR)

Comment 7

[[e-mail]]

(In reply to comment #6)
> LOCALE_SRCDIR already exists, but I guess it's now only a Makefile variable,
> so you have to manually add it to the defines that the jar builder users,
> using DEFINES += -DLOCALE_SRCDIR=$(LOCALE_SRCDIR)

Huh, actually, it's set in toolkit/locales/l10n.mk so it does exist...

Comment 8

[[e-mail]]

Oh, except this is going wrong when reticulating splines... something must have changed to make it read jar.mn files too.

Comment 9

[[e-mail]]

Ugh, the code to read jar.mn files was added last month, so it can't be that... unless it was turned on for comm-central more recently?

Comment 10

[Mike Hommey [:glandium]]

Bug 1220323 is what changed.

Using LOCALE_SRCDIR *in* a jar.mn is a bad idea anyways. You should avoid that.

Comment 11

[Edmund Wong (:ewong)]

having done some tests in the code,  LOCALE_SRCDIR isn't defined when it
hits the extra-jar.mn file.

Having also looked at every single l10n repository that uses extra-jar.mn,
none of them has any content aside for the boilerplate and/or comment.

Since I have no understanding why we have an extra-jar.mn file (nor which
conditions would have localizers add stuff to it), I'm going to have to
ask someone who knows this stuff. 

KaiRo, fredchat: while I have looked at the contents for extra-jar.mn for each 
l10n, I don't know what would be put in that file.  What exactly it's
used for.

Comment 12

[[e-mail]]

(In reply to Edmund Wong from comment #11)
> having done some tests in the code,  LOCALE_SRCDIR isn't defined when it
> hits the extra-jar.mn file.

glandium's change in bug 1220323 made it so that all the .jar files are scanned at the beginning of the build, but our .jar file uses a variable defined in l10n.mk which isn't available at the time.

If for some reason we don't want to remove it, we could always put an #ifdef around it.

Comment 13

[Edmund Wong (:ewong)]

Attachment: Remove the includesubst line and the extra-jar.mn.

going with option #2.  KaiRo (over irc) did mention that we could possibly
remove this.

Comment 14

[[e-mail]]

Comment on attachment 8688196 [details] [diff] [review]
Remove the includesubst line and the extra-jar.mn.

> 
>-# Extra l10n files for documentation and such
>-#includesubst @LOCALE_SRCDIR@/extra-jar.mn
Nit: Remove the now trailing blank line too.

Comment 15

[Edmund Wong (:ewong)]

(In reply to [e-mail] from comment #14)
> Comment on attachment 8688196 [details] [diff] [review]
> Remove the includesubst line and the extra-jar.mn.
> 
> > 
> >-# Extra l10n files for documentation and such
> >-#includesubst @LOCALE_SRCDIR@/extra-jar.mn
> Nit: Remove the now trailing blank line too.

Fixed.

Comment 16

[Edmund Wong (:ewong)]

Attachment: Remove the includesubst line and the extra-jar.mn. (v3)

Comment 17

[Edmund Wong (:ewong)]

Comment on attachment 8688321 [details] [diff] [review]
Remove the includesubst line and the extra-jar.mn. (v3)

Pushed to comm-central:
https://hg.mozilla.org/comm-central/rev/2a343f41ae69

Comment 18

[Edmund Wong (:ewong)]

Closing.  I removed the NIs; but if anyone feels that the extra-jar.mn file
needs to be re-added, please file a new bug.  However, given what :glandium
said, I think we need a new approach (if we were to require extra-jar.mn).

Comment 19

[Robert Kaiser]

(In reply to Edmund Wong (:ewong) from comment #13)
> going with option #2.  KaiRo (over irc) did mention that we could possibly
> remove this.

I think thought that this ultimately means that we'll need to remove all of our help from SeaMonkey, as this removes any way of doing a comprehensive localization of that.

Comment 20

[Mike Hommey [:glandium]]

(In reply to Robert Kaiser (:[e-mail]) from comment #19)
> (In reply to Edmund Wong (:ewong) from comment #13)
> > going with option #2.  KaiRo (over irc) did mention that we could possibly
> > remove this.
> 
> I think thought that this ultimately means that we'll need to remove all of
> our help from SeaMonkey, as this removes any way of doing a comprehensive
> localization of that.

Give one example where it's actively used. We looked at l10n-central and releases/l10n and *none* of the locales have *anything* in extra-jar.mn.

Furthermore, I see no reason for some locales to have help files that en-US wouldn't have. That's how everything else works, why would help be different?

Comment 21

[Robert Kaiser]

(In reply to Mike Hommey [:glandium] from comment #20)
> Give one example where it's actively used. We looked at l10n-central and
> releases/l10n and *none* of the locales have *anything* in extra-jar.mn.

Yes, most don't even bother to localize help. I mean, who wants to localize huge in-tree XHTML files with an almost-impossible-to-understand RDF/XML index file? Even more when the content in there is outdated and therefore incorrect in some regards?