Caveat emptor on mozbuild migration: The output of moz.build is included at the head of config/rules.mk, before config/config.mk is included. However, some Makefiles take it upon themselves to include config/config.mk themselves (typically, because they think they want to override a variable defined there before using rules.mk). Thus, moz.build variables which effect [1] things in config/config.mk may cause things to break for those files; I first noticed this with LIBRARY_NAME. This is probably a risk for many of the library-related variables. [1] Grammar nazis: that is a correct spelling there. :-)

(In reply to Joshua Cranmer [:jcranmer] from comment #1) > Caveat emptor on mozbuild migration: > > The output of moz.build is included at the head of config/rules.mk, before > config/config.mk is included. However, some Makefiles take it upon > themselves to include config/config.mk themselves (typically, because they > think they want to override a variable defined there before using rules.mk). > Thus, moz.build variables which effect [1] things in config/config.mk may > cause things to break for those files; I first noticed this with > LIBRARY_NAME. This is probably a risk for many of the library-related > variables. > > [1] Grammar nazis: that is a correct spelling there. :-) After trying to fix similar issues during freshly fetched TB (comm-central) configure, first : HOST_CSRCS in mozill/config/moz.build (Bug 893045) (commenting out how it goes, then) second :NO_DIST_INSTALL in ./mozilla/build/unix/elfhack/moz.build (again, commenting out how it goes, then) thirdly I hit LIBRARY_NAME in mozilla/mfbt/moz.build Hmm... I have no idea how to fix these, and so I have given up on local TB build for now. I am wondering how TB TryServer is handling these(?) TIA

(In reply to ISHIKAWA, Chiaki from comment #2) > After trying to fix similar issues during freshly fetched > TB (comm-central) configure, > first : HOST_CSRCS in mozill/config/moz.build (Bug 893045) > (commenting out how it goes, then) > second :NO_DIST_INSTALL in ./mozilla/build/unix/elfhack/moz.build > (again, commenting out how it goes, then) > thirdly I hit LIBRARY_NAME in mozilla/mfbt/moz.build > > Hmm... I have no idea how to fix these, and so I have given up > on local TB build for now. > I am wondering how TB TryServer is handling these(?) As I mentioned in the bug you filed, this smells very much like you have a broken checkout of mozilla-central. In particular, it sounds like you accidentally have an out-of-date copy of certain files under python/mozbuild while having non-out-of-date copies of the moz.build files.

(In reply to Joshua Cranmer [:jcranmer] from comment #3) > (In reply to ISHIKAWA, Chiaki from comment #2) > > After trying to fix similar issues during freshly fetched > > TB (comm-central) configure, > > first : HOST_CSRCS in mozill/config/moz.build (Bug 893045) > > (commenting out how it goes, then) > > second :NO_DIST_INSTALL in ./mozilla/build/unix/elfhack/moz.build > > (again, commenting out how it goes, then) > > thirdly I hit LIBRARY_NAME in mozilla/mfbt/moz.build > > > > Hmm... I have no idea how to fix these, and so I have given up > > on local TB build for now. > > I am wondering how TB TryServer is handling these(?) > > As I mentioned in the bug you filed, this smells very much like you have a > broken checkout of mozilla-central. In particular, it sounds like you > accidentally have an out-of-date copy of certain files under python/mozbuild > while having non-out-of-date copies of the moz.build files. Thank you. Clobbering was required to solve this. The version I checked out was very new as far as I could figure out (only less than 24 hours ago.) comm-central (top) hg identify c29c9f0c7405 tip (M-C portion) ./mozilla hg identify 6ee949cbeb03+ 893045-fix.patch/qbase/qtip/tip (There was one patch to fix the issue mentioned in bug 893045) After re-fetching the comm-central, just in case into a new directory, clobbering, configure succeeded and compilation is proceeding. TIA