923545 - Windows Web IDL dependencies don't seem to work perfectly yet

Status: RESOLVED DUPLICATE of bug 924992

(Firefox Build System :: General, defect)

Description

[(no longer active)]

Bug 871445 landed and then bounced because it needed clobber.  See the mochitest-2 runs on <https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=2767ff221c92>.

The build itself finished successfully, but navigator.getDataStores did not exist in the resulting build.

This is the relevant part of the patch: <https://hg.mozilla.org/integration/mozilla-inbound/rev/3986762b88a3#l18.16>.  This seems to suggest to me that the Windows NavigatorBinding.cpp was not properly regenerated.

Searching for "NavigatorBinding" in the full log <https://tbpl.mozilla.org/php/getParsedLog.php?id=28677772&tree=Mozilla-Inbound&full=1> only results in one hit:

e:\builds\moz2_slave\m-in-w32-000000000000000000000\build\obj-firefox\dom\bindings\Makefile:252:0$ echo HTMLTextAreaElementBinding NavigatorBinding > .changed-dependency-list

Comment 1

[Boris Zbarsky [:bzbarsky]]

If it ended up in .changed-dependency-list, then I would expect BindingGen.py to go ahead and regenerate the relevant .cpp file; that's the list of files it regenerates.

What's interesting to me in that log is that I see the UnifiedBindings* files generated and the corresponding .obj files compiled _before_ we ever get to the line that mentions NavigatorBinding.  In particular, that line doesn't happen until we get to building in dom/bindings/test.

There is an _earlier_ regeneration of bindings in that log, that does this:

e:\builds\moz2_slave\m-in-w32-000000000000000000000\build\obj-firefox\dom\bindings\Makefile:252:0$ echo ParserResults.pkl DataStoreBinding DataStoreChangeEventBinding > .changed-dependency-list

That one has a "Generating global WebIDL files" before it...

Why did that not pick up the change to Navigator.webidl?

Comment 2

[Gregory Szorc [:gps]]

Hopefully fixed bug 924992.

Comment 3

[(no longer active)]

(In reply to comment #2)
> Hopefully fixed bug 924992.

Did somebody actually verify that bug 924992 has fixed this?