1499156 - ./mach build fails with tup where we'd need to clobber

Status: RESOLVED WONTFIX

(Firefox Build System :: General, enhancement)

Description

[(no longer active)]

See the following output:

 0:47.75  ~ 0% 536) [0.000s] toolkit/components/places/tests/unit
 0:47.75  ~ 0% 535) [0.000s] toolkit/components/places/tests/chrome
 0:47.75  ~ 0% 534) [0.002s] obj-ff-clang-plugin.noindex/_tests/testing/mochitest/tests/toolkit/components/places/tests/chrome
 0:47.75  ~ 0% 533) [0.000s] toolkit/components/places/tests/sync
 0:47.75  ~ 0% 532) [0.000s] toolkit/components/url-classifier/tests/mochitest
 0:47.75  ~ 1% 531) [0.001s] toolkit/content/tests/browser
 0:47.75  ~ 1% 530) [0.000s] toolkit/crashreporter/test/unit
 0:47.75  ~ 1% 529) [0.000s] toolkit/crashreporter/test/unit_ipc
 0:47.75  ~ 1% 528) [0.000s] toolkit/mozapps/extensions/test/browser
 0:47.75  ~ 1% 527) [0.000s] toolkit/modules/tests/xpcshell
 0:47.75  ~ 2% 526) [0.000s] toolkit/locales/en-US/toolkit/about
 0:47.75  ~ 2% 525) [0.001s] obj-ff-clang-plugin.noindex/dist/bin/localization/en-US
 0:47.75  ~ 2% 524) [0.000s] toolkit/locales/en-US/chrome/global
 0:47.75 * ~ 2% 523) [0.001s] obj-ff-clang-plugin.noindex/dist/bin/chrome/en-US/locale/en-US/global
 0:47.75 tup error: Explicitly named file 'aboutAbout.dtd' not found in subdir 'toolkit/locales/en-US/chrome/global'
 0:47.76 tup error: Error parsing Tupfile line 17
 0:47.76   Line was: ': /home/ehsan/moz/src/toolkit/locales/en-US/chrome/global/aboutAbout.dtd |> !tup_ln |> aboutAbout.dtd $(MOZ_OBJ_ROOT)/<defau...'
 0:47.76  *** tup: 1 job failed.
 0:47.78 ===================
 0:47.78 The CLOBBER file was updated prior to this build. A clobber build may be
 0:47.78 required to succeed, but we weren't expecting it to.
 0:47.78 
 0:47.78 Please consider filing a bug for this failure if you have reason to believe
 0:47.78 this is a clobber bug and not due to local changes.
 0:47.78 ===================
 0:47.78 272 compiler warnings present.
 0:47.81 ccache (direct) hit rate: 0.0%; (preprocessed) hit rate: 0.0%; miss rate: 100.0%

I got this after a rebase from m-c on top of my objdir from a previous build...  (I've gotten errors like this several times with tup, first time filing since I just noticed the error message asks for a bug report.)

The error went away when I clobbered manually.

Comment 1

[(no longer active)]

spoke too soon.  I hit the same error after clobbering also!

Comment 2

[Chris Manchester (limited bugmail, email directly)]

That error message is probably misleading in this case. Is "obj-ff-clang-plugin.noindex" the active objdir when this error happens? If not and this objdir was previously used to build with tup this may be similar to bug 1497949, in which case the workaround is to re-configure or clobber the failing objdir before proceeding.

If that doesn't fix things, please post your mozconfig's contents so we can try to track this down. Thanks!

Comment 3

[Michael Shal [:mshal]]

I am actively working on the inactive-objdir issue in tup so that we can support the multi-objdir workflow more naturally. So if that's the case, hopefully I'll have a fix out soon, but in the meantime chmanchester's suggested workaround is the way to go.

If it's not the inactive-objdir issue (ie: if obj-ff-clang-plugin.noindex is what were you intending to build), then it sounds like we're generating something incorrectly. Can you post your mozconfig if this is the case?

Comment 4

[(no longer active)]

obj-ff-clang-plugin.noindex is an unrelated objdir.

Here is how my setup works:

  * I have .mozconfig: https://gist.github.com/ehsan/591b98c67dcec02058650223ef65baa3
  * I have .mozconfig-opt: https://gist.github.com/ehsan/3b9d4a524ac9de2ce25fc9bb21537515

When I want to work on an optimized build, I start with:

$ export MOZCONFIG=.mozconfig-opt

IIRC I *never* built in this current shell with .mozconfig, only with .mozconfig-opt, FWIW.

(BTW the workaround doesn't work as I mentioned in comment 1.  I've switched back to make for now.)

Comment 5

[(no longer active)]

(In reply to Michael Shal [:mshal] from comment #3)
> I am actively working on the inactive-objdir issue in tup so that we can
> support the multi-objdir workflow more naturally. So if that's the case,
> hopefully I'll have a fix out soon, but in the meantime chmanchester's
> suggested workaround is the way to go.

Thanks! (I posted comment 4 before seeing this, and then mid-aired...)

Comment 6

[Chris Manchester (limited bugmail, email directly)]

I was able to configure and get past parsing Tupfiles with mozconfigs similar to comment 4. Running configure for each objdir after pulling ought to work around this, but waiting for mshal's upstream fix certainly will as well.

Comment 7

[(no longer active)]

How should I know when that fix is available?

Comment 8

[Michael Shal [:mshal]]

(In reply to :Ehsan Akhgari from comment #7)
> How should I know when that fix is available?

We'll need to patch m-c to use the new version when it's ready, so I'll do that in this bug.

Comment 10

[(no longer active)]

I appreciate it, thanks!

Comment 11

[Michael Shal [:mshal]]

I had a fix for this back in the day, but unfortunately was not allowed to land it.