Wednesday, April 9, 2008

IDL Error when Building Firefox on Windows : Social Error Search

I seem to be using a different computer setup every time I build Firefox. This time, for Firefox 3.05b, Windows XP (but Windows Vista SDK) with Visual C++ 8 (Visual C++ 2005 Express Edition).

I followed the instructions on the Firefox build page: download source, install the Mozilla build tools, install the Windows SDK and also Visual C++, create a .mozconfig file, and then run 'make -f client.mk build'. And then, big surprise, I got: "midl : command line error MIDL1001 : cannot open input file oleacc.idl". This was somewhere around the ia2 folder with a bunch of Accessibility IDL files.

Long story short, I searched around the website and found the fix of extra things to disable in your .mozconfig file.

My final .mozconfig is as follows:


. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-build
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-static
ac_add_options --disable-shared
ac_add_options --disable-libxul
ac_add_options --disable-tests
ac_add_options --disable-accessibility
ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-xpconnect-idispatch


I forgot to add --disable-mochitests which would have been a good idea as well. Only --disable-accessibility and the ones below it are relevant to the fix; the rest speed up basic building and debugging.

Awhile back I wrote a little bit about search and error messages, whether by searching for a fix (taking your code from not type checking to type checking, or finding signatures for error profiles and building wikis out of them). An idea for awesomeness: inferring the search hit that fixes the bug. When trying to figure this build error out, I basically started a search session with the exact error message, and then went into a feedback loop between search engines and web pages to refine answers, until, finally, I finished and my searches were about something completely different.

Some other first-years are trying to work on semantics-aware code search, which is neat (I admit Dave's type graph work in Prospector is more in my style than their natural language approach); I want better searching of errors. Until somebody figures out a better way, I'll keep writing posts of brain dead errors like these that take a disproportionate amount of time to figure out to Google. Perhaps it's worth trying to streamline this, say by linking my browser search history to compiler output.

No comments: