1187006 - Build error, with "widget/gtk/nsApplicationChooser.h:10:10: fatal error: 'nsIApplicationChooser.h' file not found", if I don't explicitly clobber after pulling in default-to-gtk3 commit

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Daniel Holbert [:dholbert]]

Building mozilla-inbound today, I hit this build error:
{
 0:57.08 In file included from /scratch/work/builds/mozilla-inbound/obj/widget/gtk/Unified_cpp_widget_gtk0.cpp:38:
 0:57.08 In file included from /scratch/work/builds/mozilla-inbound/mozilla/widget/gtk/nsApplicationChooser.cpp:10:
 0:57.08 /scratch/work/builds/mozilla-inbound/mozilla/widget/gtk/nsApplicationChooser.h:10:10: fatal error: 'nsIApplicationChooser.h' file not found
 0:57.08 #include "nsIApplicationChooser.h"
 0:57.08          ^
 0:59.05 1 error generated.
}


My mozconfig is pretty simple:
======
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj
mk_add_options AUTOCLOBBER=1
ac_add_options --enable-debug --disable-optimize
ac_add_options --enable-warnings-as-errors
======

Comment 1

[Daniel Holbert [:dholbert]]

(I did not explicitly clobber before pulling & building, FWIW, though AUTOCLOBBER may have clobbered for me.  I've now moved my objdir out of the way to effectively get a clobber build, to see for sure whether clobber builds are affected.)

Comment 2

[Daniel Holbert [:dholbert]]

It looks like nsIApplicationChooser.h is only generated "if toolkit == 'gtk3'":
> 215 if toolkit == 'gtk3':
> 216     XPIDL_SOURCES += [
> 217         'nsIApplicationChooser.idl',
> 218     ]
http://mxr.mozilla.org/mozilla-central/source/widget/moz.build#215

...whereas nsApplicationChooser.cpp (which depends on that header) is built under a slightly different condition:
> 70 if CONFIG['MOZ_ENABLE_GTK2']:
[...]
> 74 else:
> 75     UNIFIED_SOURCES += [
[...]
> 77         'nsApplicationChooser.cpp',
> 78     ]
http://mxr.mozilla.org/mozilla-central/source/widget/gtk/moz.build#70


So it seems like the build system is assuming that *either* toolkit == 'gtk3' *or* "CONFIG['MOZ_ENABLE_GTK2']" must be true. (they're different ways of testing the same condition)

But for me in comment 0, that seems not to have been the case. My toolkit was *not* 'gtk3' (or else I would've had the header file), and CONFIG['MOZ_ENABLE_GTK2'] was *not* truthy (which is why I was building 'nsApplicationChooser.cpp'.)

Comment 3

[Daniel Holbert [:dholbert]]

OK, a clobber build completed successfully. So this seems to just be a case where a clobber is needed. (probably just due to the fact that we added a new IDL file? In retrospect, I probably didn't end up with a new .h file simply because nsIApplicationChooser.idl was new & required a clobber -- not because of the "toolkit == gtk3" check failing).

Comment 4

[Daniel Holbert [:dholbert]]

glandium, do you know if yesterday's gtk3-enabling involved a CLOBBER-file touching? (And if not, should we push a late-breaking CLOBBER-file touching, so that other people don't trip over this like I did?)

Comment 5

[Daniel Holbert [:dholbert]]

Huh -- answering my own question, it looks like bug 1186003 (the gtk3-enabling bug) *did* indeed touch CLOBBER. (It's the latest change shown by 'hg log' on my inbound repo's CLOBBER file).

So, I have no idea why I hit this issue. :-/

Comment 6

[Daniel Holbert [:dholbert]]

(I did save my busted objdir, if there's any useful information that can be gleaned from it.)

Comment 7

[Mike Hommey [:glandium]]

There was a CLOBBER for gtk3-enabling on automation, but not one for gtk3-enabling on local builds... CLOBBER was updated again today for something else.

Comment 8

[Daniel Holbert [:dholbert]]

OK, thanks.

(In reply to Mike Hommey [:glandium] from comment #7)
> CLOBBER was updated again today for
> something else.

Cool -- I verified that I was able to build, starting with my busted objdir, after I did a 'hg pull -u'. So, this seems to be WFM after today's CLOBBER update.