(no longer active) Reporter
	Description • 10 years ago

See this try push:

<https://tbpl.mozilla.org/?tree=Try&rev=bd5c2252e2c8>

In that push, I rename xpcom/typelib/xpt/tests/PrimitiveTest.c to PrimitiveTest.cpp, and change the moz.build file accordingly: <https://hg.mozilla.org/try/rev/d3a091862f3c#l188.13>

But it seems to break Valgrind builds on try.  Looking at the logs (for example:  <https://tbpl.mozilla.org/php/getParsedLog.php?id=38993956&full=1&branch=try>) it seems like this is some kind of a clobbering issue, I don't see any actual build any of the xpt files that should be built (note how this patch touches a whole bunch of .idl files) during the export phase, and then we start falling into the compile phase, again not building anything until we get to xpcom/typelib/xpt/tests and bail out because:

make[3]: *** No rule to make target `/builds/slave/try-l64-valgrind-0000000000000/src/xpcom/typelib/xpt/tests/PrimitiveTest.c', needed by `PrimitiveTest.o'.  Stop.

Not sure what's going wrong here, but I really don't think this is something related to my patch.  I've also verified that a local valgrind build using the same in-tree mozconfig sans the toolchain paths in http://mxr.mozilla.org/mozilla-central/source/build/unix/mozconfig.linux and http://mxr.mozilla.org/mozilla-central/source/build/mozconfig.cache works.

glandium, any ideas what's going on here?

	Phil Ringnalda (:philor)
	Comment 1 • 10 years ago

Personally, I don't know why we even keep running them on try, since an unclobbered try build is like a random number generator.

	(no longer active) Reporter
	Comment 2 • 10 years ago

And here is a green run after a bunch of retriggers: <https://tbpl.mozilla.org/php/getParsedLog.php?id=38996045&tree=Try&full=1>

	Mike Hommey [:glandium]
	Comment 3 • 10 years ago

Note that means your patch would probably fail on some platforms when pushed on inbound.

	(no longer active) Reporter
	Comment 4 • 10 years ago

(In reply to comment #3)
> Note that means your patch would probably fail on some platforms when pushed on
> inbound.

What should I do about that?  Land with CLOBBER?

	Mike Hommey [:glandium]
	Comment 5 • 10 years ago

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #4)
> What should I do about that?  Land with CLOBBER?

That, or find the actual problem and fix it ;)

	Trevor Saunders (:tbsaunde)
	Comment 6 • 10 years ago

> That, or find the actual problem and fix it ;)

this is probably a stale mddepend file right? there's probably an existing .deps/foo.c that doesn't get renamed when foo.c is renamed to foo.cpp, and the Makefile's mtime doesn't change because the only difference is to backend.mk.  Maybe config.status should go nuck everything in .deps/ that isn't a file it knows about? or is there something better than that?

	(no longer active) Reporter
	Comment 7 • 10 years ago

It seems like Trevor knows what's going on here, repurposing the bug.

	Trevor Saunders (:tbsaunde)
	Comment 8 • 10 years ago

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #7)
> It seems like Trevor knows what's going on here, repurposing the bug.

its only a theory ;)

it should be testeable by building without the patch, applying the patch rming objdir/xpcom/typelib/whatever/.deps/something.c and rebuilding, if that works then I'm probably right, if not its something else.

	Mike Hommey [:glandium]
	Comment 9 • 10 years ago

It's plausible, since the dep file is actually .deps/foo.o.pp, not .deps/foo.c

	Mike Hommey [:glandium]
	Comment 10 • 10 years ago

... although, dep files are supposed to have file removal protectors. That is, something like this:

foo.o: foo.c
foo.c:

which shouldn't lead to the original error.

	(no longer active) Reporter
	Comment 11 • 10 years ago

This doesn't actually block anything, I ended up landing bug 1005321 by touching CLOBBER.

	Trevor Saunders (:tbsaunde)
	Comment 12 • 10 years ago

(In reply to Mike Hommey [:glandium] from comment #10)
> ... although, dep files are supposed to have file removal protectors. That
> is, something like this:
> 
> foo.o: foo.c
> foo.c:

So, I just updated a tree and ran into this, and decided to debug it.  I'll attach PrimitiveTest.o.pp in a minute, but I'm not seeing any such remove protection mechanism, and the only rule involving PrimivitiveTest is PrimitiveTest.o: PrimitiveTest.c \ blah

	Mike Hommey [:glandium]
	Comment 14 • 10 years ago

huh, there are removal guards for headers, but not for the source. Doh.