flypig.co.uk

Yesterday I tried to forge through all the remaining bugs in the widget/qt directory. I set the full build to run overnight. It was rather a late night as well, so today things are a little shorter.

This morning there are no code errors, which is always a nice thing to see. Although the build didn't go through entirely, the fact the errors are in the build rather than the code is encouraging. Moderate your enthusiasm though: we have been here before, on Day 39 when you may recall the issue was with moc_nsNativeAppSupportQt.cpp. But I'm still a little excited. Maybe this will be the last change needed?

Either way, there's still work to be done. The error this morning is the following.

390:01.61 make[4]: *** No rule to make target 'moc_nsAppShell.cpp', needed by 'moc_nsAppShell.o'.  Stop.
390:01.61 make[3]: *** [${PROJECT}/gecko-dev/config/recurse.mk:72: widget/qt/target-objects] Error 2

A quick grep of the code highlights where this is being mentioned:

$ grep -rIn "moc_nsAppShell.cpp" *
widget/qt/moz.build:8:    '!moc_nsAppShell.cpp',

I've removed the line. Now when I try to do a partial build I hit a bump.

$ make -j1 -C ./obj-build-mer-qt-xr/widget/qt/
make: Entering directory '${PROJECT}/obj-build-mer-qt-xr/widget/qt'
${PROJECT}/gecko-dev/config/rules.mk:335: *** Build configuration changed.
  Build with |mach build| or run |mach build-backend| to regenerate build config.
  Stop.

Translated into English that essentially means that a partial build won't work: we have to do a full build instead. The Gecko build processes notices if you make changes to any of the files in the build process and (correctly) refuses to do a partial build in this case.

It's frustrating though. I wish now that I'd tried to fix this last night and then I could have left it to regenerate the build scripts overnight.

So my situation is this: I'm now on the train on my way between London and Cambridge. I have another 30 minutes of journey. Sadly I can't do any more work on this until I hit the next error, so I have to kick the build off which will take a couple of hours to run.

Not ideal, but I guess it'll give some time to relax on the train instead!

Off the build goes. Let's see how it works out later on today.

[...]

When I return to the build in the evening I discover it's not quite there yet. This error as appeared:

398:39.06 StaticComponents.cpp: In function ‘nsresult mozilla::xpcom::
          CreateInstanceImpl(mozilla::xpcom::ModuleID, nsISupports*,
          const nsIID&, void**)’:
398:39.06 StaticComponents.cpp:9850:76: error: invalid new-expression of
          abstract class type ‘mozilla::widget::GfxInfo’
398:39.06        RefPtr inst = new mozilla::widget::GfxInfo();

This error with the GfxInfo class suggests it's missing an unimplemented virtual method. It would be helpfully for confirming this if I can recreate the error by doing a partial build on xpcom/components/ like this:

make -j1 -C ./obj-build-mer-qt-xr/xpcom/components/

The StaticComponents.cpp file is unusual in that's it's entirely generated. The problem code that the error is highlighting is the following:

    case ModuleID::GfxInfo: {
      MOZ_TRY(CallInitFunc(6));
      RefPtr inst = new mozilla::widget::GfxInfo();
      MOZ_TRY(inst->Init());
      return inst->QueryInterface(aIID, aResult);
    }

So it looks like it's the GfxInfo() constructor that's causing the problem. It's defined in widget/qt/GfxInfo.h. I need to compare it against the GfxInfoBase abstract class it's inheriting from. The error output is claiming that the following methods are abstract and need definitions, and that therefore the constructor can't be used:

NS_IMETHOD GetEmbeddedInFirefoxReality(bool *aEmbeddedInFirefoxReality) = 0;
NS_IMETHOD GetTestType(nsAString& aTestType) = 0;
NS_IMETHOD GetDrmRenderDevice(nsACString& aDrmRenderDevice) = 0;

These are actually coming from a header generated from nsIGfxInfo.idl. The generating instructions look like this:

  readonly attribute boolean EmbeddedInFirefoxReality;
  readonly attribute AString testType;
  readonly attribute ACString drmRenderDevice;

These attributes get converted into Getter methods in the header file (for non-readonly attributes there would be Setter methods as well). The compiler is of course right: we're not defining these methods. However they are defined for the other platforms (Gtk, Android, etc.), so that gives us something to go on.

After looking at the existing Qt implementation of GfxInfo it looks like this might be simpler than I at first feared. Most of the existing ESR 78 methods in the class have essentially empty implementations. So I've done the same for these new methods too:

NS_IMETHODIMP GfxInfo::GetEmbeddedInFirefoxReality(bool *aEmbeddedInFirefoxReality)
{
  return NS_ERROR_FAILURE;
}

NS_IMETHODIMP GfxInfo::GetTestType(nsAString& aTestType)
{
  return NS_ERROR_FAILURE;
}

NS_IMETHODIMP GfxInfo::GetDrmRenderDevice(nsACString& aDrmRenderDevice)
{
  return NS_ERROR_FAILURE;
}

Not particularly clever, but hopefully effective.

With that change everything inside Unified_cpp_xpcom_components0.cpp and ./obj-build-mer-qt-xr/xpcom/components/ now compiles without error. For now I've not got any other errors to go on, so it's back to another full build to find out what pops up next!

I won't get the results of that until the morning, so that has to be it for now.

If you want to read my other posts related to this, you can find them in my Gecko Dev Diary.