1171249 - Building with "--disable-webspeech" triggers build error: nsLayoutModule.cpp:100:10: fatal error: 'mozilla/dom/FakeSpeechRecognitionService.h' file not found

Status: RESOLVED FIXED

(Core :: Web Speech, defect)

Description

[Daniel Holbert [:dholbert]]

Build error encountered today:
{
layout/build/nsLayoutModule.cpp:100:10: fatal error: 'mozilla/dom/FakeSpeechRecognitionService.h' file not found
 2:05.35 #include "mozilla/dom/FakeSpeechRecognitionService.h"
 2:05.35          ^
}

My mozconfig is as follows:
ac_add_options --enable-debug --disable-optimize
ac_add_options --enable-warnings-as-errors
ac_add_options --enable-profiling
ac_add_options --disable-webspeech

(I think that last line is the only one that matters for this bug's purposes.)

Comment 1

[Daniel Holbert [:dholbert]]

Seems likely to have been caused by bug 1051146.

Comment 2

[Daniel Holbert [:dholbert]]

kdavis, could you take a look at this?

Comment 3

[Daniel Holbert [:dholbert]]

Looks like the #include is only guarded by one thing:

> 99 #ifdef MOZ_WEBSPEECH_TEST_BACKEND
> 100 #include "mozilla/dom/FakeSpeechRecognitionService.h"
> 101 #endif

...whereas the actual .h file (which lives in dom/media/webspeech/recognition/) is implicitly guarded by two things:
 (1) Its grandparent directory is only processed if MOZ_WEBSPEECH is enabled:
http://mxr.mozilla.org/mozilla-central/source/dom/media/webspeech/moz.build#8
 (2) Its parent directory is only processed if MOZ_WEBSPEECH_TEST_BACKEND is enabled:
http://mxr.mozilla.org/mozilla-central/source/dom/media/webspeech/recognition/moz.build#24

So if MOZ_WEBSPEECH is off, the .h file will not be exported; but nsLayoutUtils.cpp still #includes it as long as MOZ_WEBSPEECH_TEST_BACKEND is on (which it is by default).

So, either we need to make this #ifdef more complex, or --disable-webspeech needs to turn off MOZ_WEBSPEECH_TEST_BACKEND

Comment 4

[Daniel Holbert [:dholbert]]

(side note: as a hackaround, I'm assuming I can fix my build by adding --disable-webspeechtestbackend to my mozconfig; that probably turns off MOZ_WEBSPEECH_TEST_BACKEND. The fact remains that --disable-webspeech on its own produces a busted build right now, though, and we should fix that.)

Comment 6

[kdavis]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> Looks like the #include is only guarded by one thing:
> 
> > 99 #ifdef MOZ_WEBSPEECH_TEST_BACKEND
> > 100 #include "mozilla/dom/FakeSpeechRecognitionService.h"
> > 101 #endif
> 
> ...whereas the actual .h file (which lives in
> dom/media/webspeech/recognition/) is implicitly guarded by two things:
>  (1) Its grandparent directory is only processed if MOZ_WEBSPEECH is enabled:
> http://mxr.mozilla.org/mozilla-central/source/dom/media/webspeech/moz.build#8
>  (2) Its parent directory is only processed if MOZ_WEBSPEECH_TEST_BACKEND is
> enabled:
> http://mxr.mozilla.org/mozilla-central/source/dom/media/webspeech/
> recognition/moz.build#24
> 
> So if MOZ_WEBSPEECH is off, the .h file will not be exported; but
> nsLayoutUtils.cpp still #includes it as long as MOZ_WEBSPEECH_TEST_BACKEND
> is on (which it is by default).
> 
> So, either we need to make this #ifdef more complex, or --disable-webspeech
> needs to turn off MOZ_WEBSPEECH_TEST_BACKEND

I think having --disable-webspeech turn off MOZ_WEBSPEECH_TEST_BACKEND seems
reasonable as having the test backend be there when there is no frontend it
is hooking into makes little sense.

I'll make a patch that does this, then run it through some testing.

Comment 7

[kdavis]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> Looks like the #include is only guarded by one thing:
> 
> > 99 #ifdef MOZ_WEBSPEECH_TEST_BACKEND
> > 100 #include "mozilla/dom/FakeSpeechRecognitionService.h"
> > 101 #endif
> 
> ...whereas the actual .h file (which lives in
> dom/media/webspeech/recognition/) is implicitly guarded by two things:
>  (1) Its grandparent directory is only processed if MOZ_WEBSPEECH is enabled:
> http://mxr.mozilla.org/mozilla-central/source/dom/media/webspeech/moz.build#8
>  (2) Its parent directory is only processed if MOZ_WEBSPEECH_TEST_BACKEND is
> enabled:
> http://mxr.mozilla.org/mozilla-central/source/dom/media/webspeech/
> recognition/moz.build#24
> 
> So if MOZ_WEBSPEECH is off, the .h file will not be exported; but
> nsLayoutUtils.cpp still #includes it as long as MOZ_WEBSPEECH_TEST_BACKEND
> is on (which it is by default).
> 
> So, either we need to make this #ifdef more complex, or --disable-webspeech
> needs to turn off MOZ_WEBSPEECH_TEST_BACKEND

Mid-air collision with myself!?

I think having --disable-webspeech turn off MOZ_WEBSPEECH_TEST_BACKEND seems
reasonable. Having the test backend be there when there is no frontend it is
hooking into makes little sense.

Also, having one location where this dependency

(MOZ_WEBSPEECH not defined) => (MOZ_WEBSPEECH_TEST_BACKEND not defined)

is captured makes more sense than having every MOZ_WEBSPEECH_TEST_BACKEND ifdef
capture the above dependency.

I'll make a patch that does this, then run it through some testing.

Comment 8

[kdavis]

It seems as if there might be a similar problem with MOZ_WEBSPEECH_MODELS. I will look into this too.

Comment 9

[kdavis]

Attachment: Modified configure.in so MOZ_WEBSPEECH undefined implies both MOZ_WEBSPEECH_TEST_BACKEND and MOZ_WEBSPEECH_MODELS are undefined

Modified configure.in so MOZ_WEBSPEECH undefined implies both MOZ_WEBSPEECH_TEST_BACKEND and MOZ_WEBSPEECH_MODELS are undefined

Previously if MOZ_WEBSPEECH was undefined and MOZ_WEBSPEECH_TEST_BACKEND
or MOZ_WEBSPEECH_MODELS were defined the build would fail as explained in
Comment 3

Now if MOZ_WEBSPEECH is undefined, then this forces MOZ_WEBSPEECH_TEST_BACKEND
and MOZ_WEBSPEECH_MODELS to be undefined.

Built locally, OS X building B2G, with a global mozconfig with following
cases of webspeech flags:

 1. --disable-webspeech present no other webspeech flags present
 2. --disable-webspeechtestbackend present no other webspeech flags present
 3. --disable-webspeechmodels present no other webspeech flags present

This blocks Bug 1051148 as it modifies the same portion of configure.in that
Bug modifies.

The try for this patch is running here https://treeherder.mozilla.org/#/jobs?repo=try&revision=06efebb8c119

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/44986f66ee4b

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/44986f66ee4b

Comment 12

[u532768]

This seems to be fixed in the hg pull I did today.  But I'm getting the following error.  I don't know if it is related or not.

26:27.89 ALL_CFU_SOURCE: /mnt/to_archive/accum/src/mozilla-central/intl/icu/source/data/unidata/confusables.txt /mnt/to_archive/accum/src/mozilla-central/intl/icu/source/data/unidata/confusablesWholeScript.txt
26:27.89 CFU_FILES: ./out/build/icudt52l/confusables.cfu
26:27.89 CFU_FILES_SHORT: confusables.cfu
26:27.90 gencfu writes dummy out/build/icudt52l/confusables.cfu because of UCONFIG_NO_REGULAR_EXPRESSIONS and/or UCONFIG_NO_NORMALIZATION and/or UCONFIG_NO_FILE_IO, see uconfig.h
26:27.90 generating out/tmp/icudata.lst (list of data files)
26:28.65 ar: creating ../lib/libicudata.a
26:28.97 pkgdata: /bin/ccache gcc -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DUCONFIG_NO_LEGACY_CONVERSION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_BREAK_ITERATION -DUCONFIG_NO_IDNA -DU_CHARSET_IS_UTF8 -I/mnt/to_archive/accum/src/mozilla-central/intl/icu/source/common -I/mnt/to_archive/accum/src/mozilla-central/intl/icu/source/i18n  -ffunction-sections -fdata-sections -D_REENTRANT  -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1  -DU_ATTRIBUTE_DEPRECATED= -fPIC -Wall -Wdeclaration-after-statement -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -std=gnu99 -fgnu89-inline -fno-strict-aliasing -fno-math-errno -pthread -pipe -g -UDEBUG -DNDEBUG  -O3 -DU_STATIC_IMPLEMENTATION -fvisibility=hidden   -c -I/mnt/to_archive/accum/src/mozilla-central/intl/icu/source/common -I../common -DPIC -fPIC -o ./out/tmp/icudt52l_dat.o ./out/tmp/icudt52l_dat.s
26:28.97 pkgdata: ar r ../lib/libicudata.a ./out/tmp/icudt52l_dat.o
26:28.97 pkgdata: ranlib ../lib/libicudata.a
26:28.98 Note: rebuild with "/bin/gmake VERBOSE=1 all-local" to show all compiler parameters.
26:28.98 libicu.a.desc
26:29.01 /mnt/to_archive/accum/src/mozilla-central/config/recurse.mk:32: recipe for target 'compile' failed
26:29.01 gmake[3]: *** [compile] Error 2
26:29.01 /mnt/to_archive/accum/src/mozilla-central/config/rules.mk:538: recipe for target 'default' failed
26:29.02 gmake[2]: *** [default] Error 2
26:29.02 /mnt/to_archive/accum/src/mozilla-central/client.mk:400: recipe for target 'realbuild' failed
26:29.02 gmake[1]: *** [realbuild] Error 2
26:29.02 client.mk:171: recipe for target 'build' failed
26:29.02 gmake: *** [build] Error 2
26:29.03 175 compiler warnings present.
26:30.13 Failed to parse ccache stats output: max files                          10000

Should I open a new bugzilla for this?

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to stan from comment #12)
> This seems to be fixed in the hg pull I did today.  But I'm getting the
> following error.  I don't know if it is related or not.
[...]
> Should I open a new bugzilla for this?

(1) It's unlikely that this caused new bustage (unless you're building with a combination of --disable-webspeech* mozconfig flags)
(2) I don't see any webspeech-related stuff in your pasted build output, so I think our error is likely unrelated.
(3) I think the actual build error is further back in your backscroll -- our build process is very parallelized, so often the actual compile error (with helpful error message) is followed by pages of successful build output.  So, I'm not sure the exact issue can be determined from your snippet of output in comment 12.

So: yes, please do file a new bug (or pastebin a larger stretch of your build output -- going back to a line with "error: "  and a .cpp file name, probably -- and just ask around on #developers).

Comment 14

[Daniel Holbert [:dholbert]]

(Given the mention of ICU stuff near your error, it might be worth seeing if disabling ICU that helps, via putting this in your mozconfig:
  ac_add_options --without-intl-api
But again, it's hard to know what the actual error is just from comment 12, so I don't know if that'll help.)

Comment 15

[u532768]

Thanks for your response.  I actually do have webspeech disabled.  I had opened another bugzilla for that, but it got folded into this one.  I had included my .mozconfig file there, including --disable-webspeech.

Anyway, I'll re-run the build saving all output into files.  And then I'll open a new bugzilla.  Even if it is related to this, it can always be folded into this one like the last one was.