Open Bug 833887 Opened 9 years ago Updated 2 years ago
Determine mozconfig paths and settings required to build with VS2012 Update 1
We can probably use <https://hg.mozilla.org/projects/elm/file/b800020f8ec4/build/win32/mozconfig.vs2011-win64> as a template. We might even be able to use it verbatim if the compiler paths do not change...
Note there's one important open bug in the VC11 tracking bug that would need to be resolved before we could switch. There may be other binary issues as well that we haven't found yet, although we did have vc11 builds going on elm for a couple months, and didn't run into to many problems.
Right, http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx is what I was talking about on irc. :-)
Hey Armen! Perchance do we still have those vs2012 64bit elm builders set aside someplace?
They got re-imaged :( I tried to get back things to the status quo.
(In reply to Armen Zambrano G. [:armenzg] from comment #4) > They got re-imaged :( I tried to get back things to the status quo. Ah, rats.
For reference: Bug 737994 - Get experimental Win8 Metro builds going on Elm (using vs 2012) Bug 774910 - Migrate mozilla build to the Windows 8.0 SDK In getting vs 2012 setup on a 64bit build slave chat with Armen as he's been through this before in the experimental elm builder work. In general: 1) Install the win8 sdk If you're working with an existing build slave, this should already be installed in: /c/Program\ Files\ \(x86\)/Windows\ Kits/8.0 If you're working with a fresh install, make sure to follow the same roll out steps in bug 774910 2) Install the .NET 4.0 framework http://www.microsoft.com/en-us/download/details.aspx?id=17851 3) Install Visual Studio 2012 install location: /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 11.0 4) Install vs 2012 Update 1 http://www.microsoft.com/en-us/download/details.aspx?id=35774 To build you'll need: 1) checkout of mc tip 2) the "xp compat" patch in bug 744942 3) the "buildbot" patch posted here for buildbot builds If building manually using mozilla-build, see: https://wiki.mozilla.org/Firefox/Windows_8_Integration#Building_Locally
Thanks, Jim! Do you wanna land your patch here? (We're not going to end up using it for the purposes of this investigation, so it's up to you.)
I'm not sure if these are the correct changes to be done or if this is a build config issue on my end. Please let me know if the changes make sense. Thanks
Comment on attachment 757795 [details] [diff] [review] Changes that I needed to make in order to get the build environment working on i686-pc-mingw on a Visual Studio 11.0.60315.01 Update 2 Hi there, First of all, just to note, you're not intended to set review+ and feedback+ on a patch. If you want someone to review a patch you should set review? and put someone's bugmail address in the empty field. Second, I believe the purpose of this bug is to determine the settings we'd need to build with VS2012 update 1 on our official build machines, not on a local development environment. Third, I'm not sure why you'd need this patch. Most of the things you changed don't seem to be related to building with Visual C++.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #11) > Comment on attachment 757795 [details] [diff] [review] > Changes that I needed to make in order to get the build environment working > on i686-pc-mingw on a Visual Studio 11.0.60315.01 Update 2 > > Hi there, > > First of all, just to note, you're not intended to set review+ and feedback+ > on a patch. If you want someone to review a patch you should set review? and > put someone's bugmail address in the empty field. > > Second, I believe the purpose of this bug is to determine the settings we'd > need to build with VS2012 update 1 on our official build machines, not on a > local development environment. > > Third, I'm not sure why you'd need this patch. Most of the things you > changed don't seem to be related to building with Visual C++. Thank you for the info. I agree that these changes are done in such a general location for a very specific configuration, so I do suspect that this is the wrong approach. I will try to move this information over to a separate ticket.
You need to log in before you can comment on or make changes to this bug.