Closed Bug 1495119 Opened 7 years ago Closed 2 years ago

Tup error ("Attempting to insert 'mozilla-config.h' as a generated node") when trying to build with out-of-tree objdir

Categories

(Firefox Build System :: General, defect)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: botond, Unassigned)

References

Details

Today I tried to use Tup to build an m-c tree with an out-of-tree objdir. It first told me: 0:51.96 Exception: Please run `tup init --no-sync` in a common ancestor directory of your objdir and srcdir, possibly /home/botond/dev/mozilla/. To reduce file scanning overhead, this directory should contain the fewest files possible that are not necessary for this build. The common ancestor directory in my case did not meet the "should contain the fewest files possible" criterion (in particular, it contains other srcdirs and other objdirs), but Chris encouraged me to try anyways, so I went ahead and ran the mentioned command and tried the build again. I eventually got the following error: 4:34.43 tup error: Attempting to insert 'mozilla-config.h' as a generated node when it already exists as a different type (normal file). You can do one of two things to fix this: 4:34.43 1) If this file is really supposed to be created from the command, delete the file from the filesystem and try again. 4:34.43 2) Change your rule in the Tupfile so you aren't trying to overwrite the file. 4:34.43 tup error: Attempting to insert 'mozilla-config.h.pp' as a generated node when it already exists as a different type (normal file). You can do one of two things to fix this: 4:34.43 1) If this file is really supposed to be created from the command, delete the file from the filesystem and try again. 4:34.43 2) Change your rule in the Tupfile so you aren't trying to overwrite the file. 4:34.43 tup error: Error parsing Tupfile line 7 4:34.43 Line was: ': /home/botond/dev/mozilla/central/mozilla-config.h.in $(MOZ_OBJ_ROOT)/<early-generated-files> |> ^o python /home/botond/dev...' 4:34.43 *** tup: 1 job failed. Note: /home/botond/dev/mozilla/refactoring is the srcdir I'm trying to build /home/botond/dev/mozilla is the "common ancestor" dir /home/botond/dec/mozilla/central is another srcdir which I had previously built with Tup Am I trying to do something unsupported here, or is this a bug?
Is the objdir in question from a previous make build? If so I think you'll need to manually clobber it before switching - we don't have good support for automatically switching between backends at the moment. For reference, the error here is that the Tupfile is saying it is going to write over the file 'mozilla-config.h', but it already exists on the disk before it ever ran the rule. It's a check to make sure a bad Tupfile doesn't accidentally clobber other (user-created) files.
Keywords: in-triage
Botond, were you able to proceed after clobbering the old dir where tup had been used to build? I'd be curious to hear what kind of overhead your setup incurs with tup.
Flags: needinfo?(botond)
Keywords: in-triage
(In reply to Chris Manchester (:chmanchester) from comment #2) > Botond, were you able to proceed after clobbering the old dir where tup had > been used to build? Yup. The trick was to delete /home/botond/dev/mozilla/central/.tup after choosing /home/botond/dev/mozilla as the "common ancestor" directory created a /home/botond/dev/mozilla/.tup directory. > I'd be curious to hear what kind of overhead your setup > incurs with tup. So the "scanning filesystem" step initially took abut 4 minutes. Then I moved a bunch of things I no longer use out of my "common ancestor" directory, so that I only have the source and obj dirs I actively use, and now it takes about 40-50 seconds. That's fine for a full rebuild, but it seems to take that same 40-50 seconds for incremental builds too, which significantly slows down incremental builds, so I think that could still use some improvement.
Flags: needinfo?(botond)
Severity: normal → S3

Tup is no longer supported.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.