878376 - apparently we sometimes remake idl during tier_libs

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Trevor Saunders (:tbsaunde)]

I know this sounds totally insane but
if you look at http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-inbound-ics_armv7a_gecko/1370038974/mozilla-inbound-ics_armv7a_gecko-bm61-build1-build231.txt.gz
 you'll see we compile ns{I,C}ExternalHelperAppService.idl twice once during export when we're supposed to and then later when we're building libs in uriloader/ I suspect this is the root cause of the compile failures in that log, because the compiler is unlucky enough to open nsCExternalHelperAppService.h while its being written to or something and so gets an empty file   which then leads to nsIExternalHelperAppService not being a type.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Well we compile it once in the export phase into a header file and again in the libs phase into a typelib.  Is that not what's happening?  I'm tethering so I don't want to open the log.

Comment 2

[Trevor Saunders (:tbsaunde)]

(In reply to Kyle Huey [:khuey] ([e-mail]) (afk until June 4) from comment #1)
> Well we compile it once in the export phase into a header file and again in
> the libs phase into a typelib.  Is that not what's happening?  I'm tethering
> so I don't want to open the log.

looks like that is what's happening, so I guess this is a complete mystery again.

Comment 3

[Trevor Saunders (:tbsaunde)]

> looks like that is what's happening, so I guess this is a complete mystery
> again.

I was refering to the question of why nsURILoader.cpp failed to compile

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Posting your diff would be good place to start.

Comment 5

[Trevor Saunders (:tbsaunde)]

I was looking into https://tbpl.mozilla.org/php/getParsedLog.php?id=23653020&tree=Mozilla-Inbound and https://tbpl.mozilla.org/php/getParsedLog.php?id=23653064&tree=Mozilla-Inbound Which  philor at least believes was caused by https://hg.mozilla.org/integration/mozilla-inbound/rev/1623ffc069a0

Comment 6

[Trevor Saunders (:tbsaunde)]

(In reply to Trevor Saunders (:tbsaunde) from comment #5)
> I was looking into
> https://tbpl.mozilla.org/php/getParsedLog.php?id=23653020&tree=Mozilla-
> Inbound and
> https://tbpl.mozilla.org/php/getParsedLog.php?id=23653064&tree=Mozilla-
> Inbound Which  philor at least believes was caused by
> https://hg.mozilla.org/integration/mozilla-inbound/rev/1623ffc069a0

to be clear I was looking at that because apparently clobbering fixed those errors somehow.

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

We seem to have hit this again:

https://tbpl.mozilla.org/php/getParsedLog.php?id=23699388&tree=Mozilla-Inbound

Comment 8

[Phil Ringnalda (:philor)]

Return of the original, on a merge to birch: https://tbpl.mozilla.org/php/getParsedLog.php?id=23701467&tree=Birch

Comment 9

[Phil Ringnalda (:philor)]

And perhaps (only perhaps because I actually don't have any idea what _this_ is) https://tbpl.mozilla.org/php/getParsedLog.php?id=23703277&tree=Mozilla-Inbound

Comment 10

[Gregory Szorc [:gps]]

Hopefully this goes away after bug 850380.

Comment 11

[Gregory Szorc [:gps]]

I'm going to assume bug 850380 fixes this.