Boris Zbarsky [:bzbarsky] Reporter
	Description • 10 years ago

This is a bit weird...  And is happening in a tree which has the fix for bug 983185, so that's not the issue here.

Steps to reproduce:

1)  Create a patch that adds a .webidl file.
2)  mach build dom/bindings.
3)  qpop the patch created in step 1.
4)  Create a patch that changes the codegen.
5)  mach build dom/bindings.
6)  qpush the patch created in step 1.
7)  mach build dom/bindings.

EXPECTED RESULTS: The codegen changes made in step 4 affect the generated files created for the patch from step 1.

ACTUAL RESULTS: The generated files remain as they were after step 2; they are not regenerated to take the codegen changes into account.

If the "mach build dom/bindings" is replaced by "mach build" in all of the above steps, then the bug doesn't happen.  However, doing a "mach build" after the 7 steps above doesn't regenerate the bindings either.

	Gregory Szorc [:gps]
	Comment 3 • 10 years ago

I'm a bit worried these STR are valid.

(In reply to Boris Zbarsky [:bz] from comment #0)
> If the "mach build dom/bindings" is replaced by "mach build" in all of the
> above steps, then the bug doesn't happen.  However, doing a "mach build"
> after the 7 steps above doesn't regenerate the bindings either.

This seems to imply it's a partial tree building problem.

Can you verify "Reticulating splines" is occurring every time a moz.build changes? |mach build dom/bindings| should cause it to.

On my personal build, Codegen.py is listed as a global dependency. So changing it should result in everything being regenerated.

	Gregory Szorc [:gps]
	Comment 4 • 10 years ago

Actually, not a clobber issue since full build apparently doesn't repro.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 5 • 10 years ago

> Can you verify "Reticulating splines" is occurring every time a moz.build changes?

It is as far as I can tell.

The key part here, I suspect, is that during step 5 (when the Codegen.py has gotten changed), the binding in question is not in the moz.build but the generated files for it are still around (and don't get updated, because they're not in our moz.build; that part is fine).  Then in step 7 they don't get regenerated... I'm not sure why.  I'd expect them to get regenerated at that point.

	Gregory Szorc [:gps]
	Comment 6 • 10 years ago

Oh, I see what's going on.

We use hash-based validation (rather than mtime) for determining whether to regenerate output files.

When Codegen.py changes, all existing files are regenerated. But the "orphaned" file is overlooked. Then, the orphaned file becomes relevant again. But, it's old dependency info has been lost and it looks like it is up to date so it doesn't regenerated.

There are a few potential solutions. I think the easiest is to remove orphaned output files.

Does this issue warrant immediate attention? If not, it will likely sit orphaned for weeks unless someone outside the build module wants to have a go at it.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 7 • 10 years ago

It confused the heck out of me for a few mins, but figuring out that "touch dom/bindings/Codegen.py" fixes wasn't that hard in my case...  Not sure it'll affect others much; most people aren't both changing codegen and adding webidl files then building in just the bindings dir.