Building mozilla code directly from Visual Studio IDE

visual-studio-mozilla-build-ide-error-list

 

Yes, it's possible!  With a single key press you can build and have a nice list of errors in the Error List window, clickable to get to the bad source code location easily.  It was a fight, but here it is.  Tested with Visual Studio Express 2013 for Windows Desktop, but I believe this all can be adapted to any version of the IDE.

 

  • Create a shell script, you will (have to) use it every time to start Visual Studio from mozilla-build's bash prompt:

export MOZ__INCLUDE=$INCLUDE
export MOZ__LIB=$LIB
export MOZ__LIBPATH=$LIBPATH
export MOZ__PATH=$PATH
export MOZ__VSINSTALLDIR=$VSINSTALLDIR
# This is for standard installation of Visual Studio 2013 Desktop, alter the paths to your desired/installed IDE version
cd "/c/Program Files (x86)/Microsoft Visual Studio 12.0/Common7/IDE/"
./WDExpress.exe &

  • Create a solution 'mozilla-central' located at the parent directory where your mozilla-central repository clone resides.  Say you have a structure like C:\Mozilla\mozilla-central, which is the root source folder where you find .hg, configure.in and all the modules' sub-dirs.  Then C:\Mozilla\ is the parent directory.
  • In that solution, create a Makefile project 'mozilla-central', again located at the parent directory.  It will, a bit unexpectedly, be created where you probably want it - in C:\Mozilla\mozilla-central.
  • Let the Build Command Line for this project be (use the multi-line editor to copy & paste: combo-like arrow on the right, then the <Edit...> command):

call "$(MOZ__VSINSTALLDIR)\VC\bin\vcvars32.bat"
set INCLUDE=$(MOZ__INCLUDE)
set LIB=$(MOZ__LIB)
set LIBPATH=$(MOZ__LIBPATH)
set PATH=$(MOZ__PATH)
set MOZCONFIG=c:\optional\path\to\your\custom\mozconfig
cd $(SolutionDir)
python mach --log-no-times build binaries


 

Now when you make a modification to a C/C++ file just build the 'mozilla-central' project to run the great build binaries mach feature and quickly build the changes right from the IDE.  Compilation and link errors as well as warnings will be nicely caught in the Error List.

BE AWARE: There is one problem - when there is a typo/mistake in an exported header file, it's opened as a new file in the IDE from _obj/dist/include location.  When you miss that and modify that file it will overwrite on next build! Using CreateHardLink might deal with this issue.

With these scripts you can use the Visual Studio 2013 IDE but build with any other version of VC++ of your choice.  It's independent, just run the start-up script from different VS configuration mozilla-build prompt.

I personally also create projects for modules (like /netwerk, /docshell, /dom) I often use.  Just create a Makefile project located at the source root directory with name of the module directory.  The project file will then be located in the module - I know, not really what one would expect.  Switch Solution Explorer for that project to show all files, include them all in the project, and you are done.

Few other tweaks:

  • Assuming you properly use an object dir, change the Output Directory and Intermediate Directory to point e.g. to $(SolutionDir)\<your obj dir>\$(Configuration)\.  The logging and other crap won't then be created in your source repository.
  • Add:
    ^.*\.vcproj.*
    ^.*\.vcxproj.*
    .sln$
    .suo$
    .ncb$
    .sdf$
    .opensdf$
    to your custom hg ingnore file to prevent the Visual Studio project and solution files interfere with Mercurial.  Same suggested for git, if you prefer it.

 

Note: you cannot use this for a clobbered build because of an undisclosed Python Windows-specific bug.  See here why.  Do clobbered builds from a console, or you may experiment with clobber + configure from a console and then build from the IDE.

9 thoughts on “Building mozilla code directly from Visual Studio IDE”

  1. Want to add the information to MDN? I think several people using Windows have asked about this.

    Reply

    1. Yep, sounds good. I'll do it sometimes next week and publish the link here. Probably worth a dev-platform post then too.

      Reply

  2. Thanks for working this out and publishing this! I couldn't copy & paste the multi-line build command into Visual Studio 2012, so I made it into a batch file instead, that accepts a command line argument that was the path to the solution dir:

    IF %1.==. GOTO NoPath

    call "%MOZ__VSINSTALLDIR%\VC\bin\vcvars32.bat"
    set INCLUDE=%MOZ__INCLUDE%
    set LIB=%MOZ__LIB%
    set LIBPATH=%MOZ__LIBPATH%
    set PATH=%MOZ__PATH%
    cd %1
    c:\mozilla-build\python\python.exe mach --log-no-times build binaries

    GOTO End

    :NoPath
    ECHO Please provide path to mozilla code dir.
    GOTO End

    :End

    I also found that when I had an error in a header file and I clicked on the error in the error list to jump to the error in the code, VS jumped to the copy of the header file in the objdir, not the file in the src dir. I'm pretty sure Bas Schouten has a solution for this, and he showed me a few years ago but I've lost it since unfortunately.

    Reply

    1. You can open an editor for multi-line Build Command Line entry. When it has focus, there is the classic 'combo expand' down-arrow. Press on it and there is an <Edit...> option. It opens a window with a text area where you can past the multi-line command. I'll update the post.

      And yes, there is the problem with opening exported headers instead their original in the source dir. I've never found a solution so far however it can be annoying and actually can lead to loosing your work. I'll try to contact him.

      Thanks!

      Reply

  3. OK, one safeguard against the problem of the debugger using headers from the objdir is to mark them read-only at the end of the build operation; add the following to your build command:

    attrib +R /S objdir\dist\include\*.*

    This makes it harder for you to start editing the objdir headers thinking they're the srcdir headers.

    I also remembered how to get tab completion etc working in a project. You just need to add your files as existing files to the project. They won't be compiled, since you've got a distinct build command.

    Also, I've written a python script to generate a solution file with the environment variables hard coded into the project file, there's no need to pass through the environment in MOZ__INCLUDE anymore. The idea being that (eventually) you'll be able to type ./mach msvc20XX-solution and then just open the solution and press CTRL+B and Firefox will build. It mostly works, except that the build command *only* works if you startup Visual Studio from the MozillaBuild shell. If I startup Visual Studio from a desktop short cut and build, I get an error "Windows Error: [Error 193] %1 is not a valid Win32 application". I think this is related to a mismatch in 32bit and 64bit DLLs, I haven't had a chance to investigate it further. I am going to continue trying to get it working.

    Reply

    1. The READ/ONLY idea for obj/dist is really good. Today I just caught my self again with this issue.

      And the mach idea? Oh, I love it! I think people will be very happy with that.

      You can use Benoit's way to build w/o running VS from the bash shell. However, this way you loose the Error List connection since a new MSYS window with all the output is open what VS IDE cannot hook to.

      Reply

  4. You also need to remove the read-only attributes on the objdir header files, else subsequent builds will fail with a permission error when they try to delete the old headers.

    Reply

    1. Yeah, I know and I'm watching it from its early times, but I personally still prefer my solution over it. This blog post is here for (somewhat my own) reference.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.