1438961 - (C-C) Building with --disable-tests fails due to compilation error caused by a missing header file, mozITestInterfaceJS.h

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[ISHIKAWA, Chiaki]

I have found that the current C-C tree (with its M-C mozilla subdirectory)
does't build if I have --disable-tests in mozconfig.

ac_add_options --disable-tests

The build failure is as follows:

/new-hd1/extra/ishikawa/TB-3HG/comm-central/mozilla/dom/bindings/test/TestFunctions.cpp:10:33:

fatal error: mozITestInterfaceJS.h: No such file or directory
  0:13.88  #include "mozITestInterfaceJS.h"

After some investigative work, I have found that
there is NO mozITestInterfaceJS.h after clobbering and configuring 
when there is --disable-tests in mozconfig.

But once I comment out --disable-tests, and clobber and configure, I do see
the following file generated under my MOZOBJ directory.

   dist/include/mozITestInterfaceJS.h

So there is something wrong with the configuration.
By the way, such a problem was not noticed before. This happened fairly recently, I think. 

I think the correct solution would be

- do not compile mozilla/dom/bindings/test/TestFunctions.cpp when there is
  --disable-tests in mozconfig.

Some patch contributors including myself make sure that the newly created patches compile on a local PC (i.e., making sure the build succeeds) on the road, but test on other machines at home, etc.
Simply making sure that patches created for C++ files (and maybe some JS files)
will not break build (and WITHOUT tests) requires less compilation on a PC and should be supported: test programs need not be compiled on that PC.
This arrangement of having one PC with test enabled  and another PC
without test enabled has worked for many months (or years) until recently.

Hmm. There seems to be fixed bug as follows:
Bug 1230778
[trunk] make package is broken if --disable-tests is used in .mozconfig

That bug deals with a failure during packaging state and not with compilation error.


TIA

Comment 1

[Tom Prince [:tomprince]]

Can you reproduce this with a Firefox build?

Comment 2

[ISHIKAWA, Chiaki]

(In reply to Tom Prince [:tomprince] from comment #1)
> Can you reproduce this with a Firefox build?

I don't have pure FF source tree handy.
It has to wait until Sunday (it is Saturday morning about 10 o'clock in Japan, and I need to go out now).

TIA

Comment 3

[ISHIKAWA, Chiaki]

(In reply to ISHIKAWA, Chiaki from comment #2)
> (In reply to Tom Prince [:tomprince] from comment #1)
> > Can you reproduce this with a Firefox build?
> 
> I don't have pure FF source tree handy.
> It has to wait until Sunday (it is Saturday morning about 10 o'clock in
> Japan, and I need to go out now).
> 
> TIA

Come to think of it, I could build FF under M-C mozilla subdirectory.

So I tried, and yes, I get the same error when the mozconfig for FF contains
--disable-tests:

The same error caused by missing mozITestInterfaceJS.h:

...
libdom_filesystem_compat.a.desc
In file included from /home/ishikawa/ff-objdir-tb3/dom/bindings/Unified_cpp_dom_bindings0.cpp:110:0:
/NREF-COMM-CENTRAL/comm-central/mozilla/dom/bindings/test/TestFunctions.cpp:10:33: fatal error: mozITestInterfaceJS.h: No such file or directory
 #include "mozITestInterfaceJS.h"
                                 ^
compilation terminated.
/NREF-COMM-CENTRAL/comm-central/mozilla/config/rules.mk:1047: recipe for target 'Unified_cpp_dom_bindings0.o' failed
make[4]: *** [Unified_cpp_dom_bindings0.o] Error 1
make[4]: *** Waiting for unfinished jobs....
libdom_flex.a.desc
libdom_gamepad.a.desc
...

So it seems that it *IS* a problem in M-C portion.

Comment 4

[André Bargull [:anba]]

I've just hit the same problem when building Firefox locally.

It looks like mozITestInterfaceJS was added in bug 1424362, maybe :bz knows what to do here?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Why would --disable-tests affect the existence of mozITestInterfaceJS.h?  I don't see anything in there conditioned on ENABLE_TESTS.

Comment 6

[Boris Zbarsky [:bzbarsky]]

"in there" == "under dom/bindings or dom/webidl"

Comment 7

[Boris Zbarsky [:bzbarsky]]

I mean, in general we _could_ try turning off parts of this if not ENABLE_TESTS.  But that would actually make build bustage with --disable-tests _more_ likely, because I'm pretty sure people would get this wrong.  Which is why right now it's all just based on DEBUG and ignores ENABLE_TESTS.

Comment 8

[André Bargull [:anba]]

Maybe mozITestInterfaceJS.h is not available because mozITestInterfaceJS.idl is placed in "dom/bindings/test" and "dom/bindings/test" gets included through TEST_DIRS [1]. And IIUC TEST_DIRS only seems to be consulted when ENABLE_TESTS is true (bug 1234955).

[1] https://searchfox.org/mozilla-central/rev/b469db5c90d618f4b202d5ef280e1a78224eb43b/dom/bindings/moz.build#10

Comment 9

[Boris Zbarsky [:bzbarsky]]

Ah, I see.  OK, let me look into what the sanest way to fix this is.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Make DOM binding bits build in a debug --disable-tests build

I've verified that both normal and --disable-tests debug builds work with this change.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2a30ffeb2f1d
Make DOM binding bits build in a debug --disable-tests build.  r=qdot

Comment 12

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/2a30ffeb2f1d

Comment 13

[ISHIKAWA, Chiaki]

Nice. Thank you.