515011 - Build break in browser/locales

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Peter Weilbacher]

Trying to build the FF 3.5.3 release on OS/2 I find that my build breaks with the following error:

make.exe[2]: Entering directory `M:/Fx35/353/browser/locales'
Traceback (most recent call last):
  File "M:/Fx35/mozilla-1.9.1/config/Preprocessor.py", line 477, in ?
    main()
  File "M:/Fx35/mozilla-1.9.1/config/Preprocessor.py", line 462, in main
    pp.handleCommandLine(None, True)
  File "M:/Fx35/mozilla-1.9.1/config/Preprocessor.py", line 168, in
    handleCommandLine self.do_include(f)
  File "M:/Fx35/mozilla-1.9.1/config/Preprocessor.py", line 430, in do_include
    raise Preprocessor.Error(self, 'FILE_NOT_FOUND', str(args))
__main__.Error: ('', 0, 'FILE_NOT_FOUND', 'M:/Fx35/353/browser/locales/.26346')
make.exe[2]: *** [libs] Error 1
make.exe[2]: Leaving directory `M:/Fx35/353/browser/locales'

I think this is due to bug 505491 and my setting of

  [defaults]
  identify = -n -i -b -t

in ~/.hgrc. So my output is something like this:

  $ hg id -n -r .
  0da982f65d37b96c5be0420237836aeac2e527e7 26257 GECKO1913_20090824_RELBRANCH FIREFOX_3_5_3_BUILD1 FIREFOX_3_5_3_RELEASE

As Hg repos can have different numerical IDs for the same changeset (although I never understood how that could happen I have seen it) the numerical revision isn't a good identifier anyway...

Comment 1

[Axel Hecht [:Pike]]

The numerical identifier it perfectly fine for the scenarios it's supposed to cover.

We have multiple things in the tree that will break the build if you tweak your id settings, notably in about:buildconfig.

I somewhat think this is an hg bug, and not something we can fix. Dirkjan, anything we could do there?

Comment 2

[Dirkjan Ochtman (:djc)]

Yeah, we recognize that [defaults] can be an issue for scripting etc. We've been looking at adding a flag to disobey all [defaults] section (additionally there are people who want to deprecate [defaults] in favor of [alias]). So consider this a hg bug for now, we hope to improve this in 1.4.

Comment 3

[Dirkjan Ochtman (:djc)]

BTW, you might be able to use hg --config defaults.id="" to override this kind of thing... But overriding the identify command at this point isn't a very good idea.

Comment 4

[Axel Hecht [:Pike]]

hg --config defaults.identify="" id -n

seems to work. Up to ted on whether we want to jump throuhg that loop or not.

Comment 5

[Peter Weilbacher]

OK, that works nicely, yes.

The makefiles creating the ID in about:buildconfig are not broken because they use the changeset ID which is listed first in the |hg id| output. The rest of the output is cut off, so they don't need any workaround.

Comment 6

[(not currently active) Ted Mielczarek]

I don't really care. If you want to add that to support this, that's fine, but this is the first I've heard of anyone running into this, so I doubt it's a common issue.

Comment 7

[Peter Weilbacher]

I also don't care any more. With the workaround of comment 4 this works nicely. And as I have to patch any "hg identify" in the tree anyway for OS/2 builds (because we need at least a different nsprpub/configure and hence I have to use |hg id -r qparent| everywhere to get meaningful IDs), I can do that change locally.
--> WONTFIX