This is the error that I get: === Building ANGLE via devenv.exe === not_ranlib angle.lib Upgrading solution... /usr/bin/sh: line 5: devenv: command not found c:\mozilla-central\obj-ff-dbg\gfx\angle\Makefile:169:0: command '(echo "=== Building ANGLE via devenv.exe ===" \ && rm -rf angle-build && mkdir angle-build \ && cp -r ../../../gfx/angle/src ../../../gfx/angle/include angle-build \ && cd angle-build/src \ && echo "Upgrading solution..." \ && devenv angle.sln //upgrade \ && echo "Building solution, target Debug|Win32..." \ && ( devenv angle.sln //useenv //build "Debug|Win32" //out ../../angle-build-log.txt \ || (cat ../../angle-build-log.txt && exit 1) \ ) \ && echo "Copying dlls..." \ && cp Debug/*.dll ../.. \ && cd ../.. \ && echo "Extracting dlls from cab file..." \ && expand "C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)/Redist/Jun2010_d3dx9_43_x86.cab" . -F:d3dx9_43.dll \ && expand "C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)/Redist/Jun2010_D3DCompiler_43_x86.cab" . -F:D3DCompiler_43.dll \ )' failed, return code 127 <libs>: Found error <libGLESv2.dll>: Found error <libs>: Found error c:\mozilla-central\config\rules.mk:955:0: command 'c:/mozilla-build/python/python.exe c:/mozilla-central/build/pymake/pymake/../make.py -C angle libs' failed, return code 2 c:\mozilla-central\config\rules.mk:785:0: command 'c:/mozilla-build/python/python.exe c:/mozilla-central/build/pymake/pymake/../make.py -C gfx li bs' failed, return code 2 c:\mozilla-central\config\rules.mk:796:0: command 'c:/mozilla-build/python/python.exe c:/mozilla-central/build/pymake/pymake/../make.py libs_tier _platform' failed, return code 2 c:\mozilla-central\config\rules.mk:746:0: command 'c:/mozilla-build/python/python.exe c:/mozilla-central/build/pymake/pymake/../make.py tier_pla tform' failed, return code 2 c:\mozilla-central\client.mk:345:0: command 'c:/mozilla-build/python/python.exe c:/mozilla-central/build/pymake/pymake/../make.py -j8 -s -C c:/mo zilla-central/obj-ff-dbg' failed, return code 2 In VC9 express, there is no devenv.com executable. The IDE shortcut points to "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\VCExpress.exe". This means that we are breaking a supported build configuration on Windows, and I think we should maintain keeping it working, because we do not want to make people obtain a Visual C++ license just to be able to compile Firefox on Windows. The obvious and simple solution to this problem is to just write a makefile for angle.

(In reply to comment #0) > The obvious and simple solution to this problem is to just write a makefile for > angle. If you want to take this on, that'd be great; I tried and stopped, because while it would be relatively straightforward, it needs to be largely separate from our current build system. The EGL/GLESv2 bits of ANGLE need to be compiled with things like exceptions that our system isn't really set up to support, and many of our cflags etc. do weird things. An easy fix for now would be to --disable-angle; we could add a configure check for devenv and automatically disable it with a warning. I agree that we should keep VC Express working, though.

(In reply to comment #1) > (In reply to comment #0) > > The obvious and simple solution to this problem is to just write a makefile for > > angle. > > If you want to take this on, that'd be great; I tried and stopped, because > while it would be relatively straightforward, it needs to be largely separate > from our current build system. The EGL/GLESv2 bits of ANGLE need to be > compiled with things like exceptions that our system isn't really set up to > support, and many of our cflags etc. do weird things. Oh, that sounds a lot harder than what I assumed (basically adding a list of source file to CPPSRCS!) :-) > An easy fix for now would be to --disable-angle; we could add a configure check > for devenv and automatically disable it with a warning. I agree that we should > keep VC Express working, though. Yes, Benoit suggested the same thing to me in person, and like I said to him, I think this is a brilliant idea. If fixing this for real is not easy, then let's use this bug to get a configure.in check for devenv.exe, and use --disable-angle automatically if we fail to find the executable.

(In reply to comment #3) > *** Bug 633781 has been marked as a duplicate of this bug. *** OK, OK, I prioritize it :-)

No, we must not automatically disable features, although we should issue a compile-time error. Why can't we export the ANGLE project as nmake makefiles? Doesn't MSVC do that anymore?

(In reply to comment #5) > No, we must not automatically disable features, although we should issue a > compile-time error. > > Why can't we export the ANGLE project as nmake makefiles? Doesn't MSVC do that > anymore? Can't we use VCBuild? <http://msdn.microsoft.com/en-us/library/hw9dzw3c%28v=VS.90%29.aspx> (We should check to make sure that it's available on VC express, though -- Benoit, the Alienware machine on my desk has VC2008 Express installed in case you want to check this out).

(In reply to comment #7) > http://blog.emptycrate.com/node/393 Then VCBuild is what we should be using! Thanks for digging into this.

Works on my Windows 7 box with Mozilla Build 1.5.1 and Visual C++ 2005 Express. Not tested with other version of Visual C++ yet.

I wouldn't take this patch, FWIW. You should check for devenv / vcbuild in configure, and pick whichever one is available.

It's a good start though. Nice to have a tested example of how to use VCBuild.

VC10 (including Express) does no longer contain VCBuild. http://msdn.microsoft.com/en-us/library/dd465215.aspx So checking for VC10EXPRESSDIR is redundant.

Working in progress. It seems that some code has to be left in gfx/angle/Makefile.in, because vcbuild does not share the same syntax with devenv and some command needs ANGLE_DIR as a part of its argument. It may take some days to add VC10 support, for supporting MSBuild seems to need some extra work.

I think you only need to move the test+define for USING_VC_EXPRESS into configure, the rest should stay in gfx/angle/Makefile.in. BTW, you sometimes spell angle as angel.

If it turns out that adding VC10 support is a lot of work (from what I understand, it will be), then it's better to do that in a new bug, so it doesn't hold this up. And I was just informed that since we'll have three options, the define should be something like ANGLE_BUILD_TOOL={devenv,vcbuild,msbuild} (configure can figure out which one of those), instead of having two separate ones (USING_VC_EXPRESS, USING_MS_BUILD).

MSBuild itself doesn't support building with older VC++ projects (.vcproj). It depends on VCBuild to build those projects. If it couldn't find VCBuild, it will spit out an error message about the dependency and stop building. Thus VC10 Express users will be required to install VC8 Express or .NET Framework 2.0 SDK anyway. I suggest using VCBuild directly and adding a variable like ANGLE_BUILD_TOOL_PATH to locate VCBuild, rather than being bothered with MSBuild.

Since supporting MSBuild means a lot of work, let's just require devenv or vcbuild currently. To build with VC10 Express, install something bundled VCBuild, and append the location of vcbuild.exe to PATH. Adding a specific variable to locate VCBuild makes build scripts a little complicate. So I suggest doing it later if necessary.

SUN Haitao, do you consider updating a patch and requesting review?

Since attachment 520882 [details] [diff] [review] is not reviewed yet, I have no idea on what to update.

You need to request review to get reviewed. And you will have to update the patch first because the patch does no longer apply to latest trunk. See https://developer.mozilla.org/en/Hacking_Mozilla about how to request review.

My fault. Let me do this this weekend.

This bug should no longer exist since bug 641630: we do no longer run devenv.exe, instead Joe wrote Makefiles for all of ANGLE. Please reopen if there still exist build issues on this compiler.