Bug 77517 – Visual Studio 2010 toolchain support

• Component: Tools / Tests
• Status: RESOLVED DUPLICATE

[Ashod Nakashian]

Created attachment 124896 [details]
VS2010 support scripts

Currently VS2005 and VS2008 are recognized and supported by pdevenv script. There is growing need to add support for VS2010 toolchain. Supporting VS2010 will help some of us fix compiler issues related to the newer compiler and accelerate the eventual transition to using VS2010 primarily. This need to transition to VS2010 is heightened by the fact that VS2005 lacks support on Windows 7, which is increasingly becoming dominant.

In recognition to the need to support VS2005 for the foreseeable future, and the maintenance overhead associated with supporting two sets of project and property-sheet files (due to VS2010's departure from the old format used by VCBuild and earlier VS versions,) an effort must be made to support only the mainline set of files. Currently the mainline is VS2005 and we should keep supporting it until it's completely phased out (back-porting the files is a much harder task than going in the other direction.)

Besides the maintenance issues pointed out, the main hurdle to supporting VS2010 is the compiler errors. It turns out this may be (temporarily) circumvented as the errors are actually due to warnings. See bug #34804.

I've spent some time and have successfully built WebKit WinCairo on Windows 7. The resulting binaries are fully functional, although I didn't run the test suite yet. I also plan to build the CoreGraphics version in the coming days, hopefully no surprises there either.

I've written about the experience of porting WebKit to VS2010 (on Windows 7) and issues I came across and how I solved them on my personal blog: http://blog.ashodnakashian.com/2012/01/building-webkit-on-windows-7-with-vs2010

My port fully honors the requirements to support VS2005 and to avoid adding a second set of project and property-sheet files by first automatically upgrading the solution/project files using VS2010, which generates new files leaving old ones intact. In addition, all changes necessary to fix build errors automated and are completely transparent.

I limited my patch to exactly one file: pdevenv. I've also added a new Windows batch file only for convenience, but it's completely optional and may be left out (although I strongly recommend committing it.) The batch file in question mounts the source directory, sets up the environment and launches CygWin. The modified script, pdevenv, only adds support to VS2010 and, via perlre, fixes some of the files to get a clean build.

I've taken the liberty to attach the two files for review. I believe this approach is the least intrusive/disruptive and does give the community full VS2010 support. I await comments and criticism.

[WebKit Review Bot]

Attachment 124896 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files']" exit_code: 1

Total errors found: 0 in 0 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Ashod Nakashian]

Created attachment 125493 [details]
Patch

[Ashod Nakashian]

Created attachment 125495 [details]
Patch

[Patrick R. Gansterer]

FYI: There is already something similar: bug 53445

I don't like the idea of adding support of an "additional" build system (=VS2010), so I've already done the main part of porting the VS2005 files to CMake, where the used toolchain (VS2005, VS2008, VS2010, or even VS2011) does not matter. The work can be found at 72816. It's not 100% finished because I don't have much time to work on Webkit in the resent past :-(. But any work pushing this forward is welcome. ;-)

[Ashod Nakashian]

(In reply to comment #4)
> FYI: There is already something similar: bug 53445
> 
> I don't like the idea of adding support of an "additional" build system (=VS2010), so I've already done the main part of porting the VS2005 files to CMake, where the used toolchain (VS2005, VS2008, VS2010, or even VS2011) does not matter. The work can be found at 72816. It's not 100% finished because I don't have much time to work on Webkit in the resent past :-(. But any work pushing this forward is welcome. ;-)

I agree with your point about addition support overhead. I think the best of all worlds would be something like GYP.

Having said that, I think my patch still has some valuable benefits to offer. The main advantage, IMHO, is that with this small patch we can have a working vs2010 build system where we can do all the porting work to get no warnings etc, while in parallel we develop a unified build system. With a new build system (be it CMake or GYP) we will be working on two things at the same time: the build scripts and porting the code.

In any event, even if we don't get a vote to commit my patch, it could still be of value to those working on the port. My aim with this bug is simply to add support for vs2010 with minimum effort/disruption. As for bug 53445, I'd love to help, but first I think we must settle the question of build the system: CMake or GYP or something else?

[Patrick R. Gansterer]

(In reply to comment #5)
> (In reply to comment #4)
> > FYI: There is already something similar: bug 53445
> > 
> > I don't like the idea of adding support of an "additional" build system (=VS2010), so I've already done the main part of porting the VS2005 files to CMake, where the used toolchain (VS2005, VS2008, VS2010, or even VS2011) does not matter. The work can be found at 72816. It's not 100% finished because I don't have much time to work on Webkit in the resent past :-(. But any work pushing this forward is welcome. ;-)
> 
> I agree with your point about addition support overhead. I think the best of all worlds would be something like GYP.
> 
> Having said that, I think my patch still has some valuable benefits to offer.
I agree. :-)

> In any event, even if we don't get a vote to commit my patch, it could still be of value to those working on the port. My aim with this bug is simply to add support for vs2010 with minimum effort/disruption. As for bug 53445, I'd love to help, but first I think we must settle the question of build the system: CMake or GYP or something else?

CMake is already used for EFL and WinCE, so the "platform abstraction of the buildsystem" is already done there. I also created the CMake files for Wx (bug 73100) and WindowsApple (bug 72816), so I think it's the easiest way.

[Ashod Nakashian]

(In reply to comment #6)
> CMake is already used for EFL and WinCE, so the "platform abstraction of the buildsystem" is already done there. I also created the CMake files for Wx (bug 73100) and WindowsApple (bug 72816), so I think it's the easiest way.

What remains to be done? If you could give me some pointers on what outstanding work there is, may be I can chip in.

[Patrick R. Gansterer]

(In reply to comment #7)
> (In reply to comment #6)
> > CMake is already used for EFL and WinCE, so the "platform abstraction of the buildsystem" is already done there. I also created the CMake files for Wx (bug 73100) and WindowsApple (bug 72816), so I think it's the easiest way.
> 
> What remains to be done? If you could give me some pointers on what outstanding work there is, may be I can chip in.

*) You need to "rebase" the patch, since the patch does not consider the changes since I uploaded it.
*) The build targets from the Tool directory need some love too
*) Make reviewables patches out of it.

[Ashod Nakashian]

(In reply to comment #8)
> *) You need to "rebase" the patch, since the patch does not consider the changes since I uploaded it.
> *) The build targets from the Tool directory need some love too
> *) Make reviewables patches out of it.

Sounds fun. But if you don't mind me asking, besides the second point, any reason why it wasn't reviewed and committed (anything I should look out for)?

Also, where can I get some tips on configuring and running the CMake build?

Thanks!

[Dirk Pranke]

I don't think we need to settle on one build system; even if we got down to just CMake, GYP, and XCode (for the Apple Mac port), that would be a big improvement.

[Patrick R. Gansterer]

(In reply to comment #9)
> (In reply to comment #8)
> > *) You need to "rebase" the patch, since the patch does not consider the changes since I uploaded it.
> > *) The build targets from the Tool directory need some love too
> > *) Make reviewables patches out of it.
> 
> Sounds fun. But if you don't mind me asking, besides the second point, any reason why it wasn't reviewed and committed (anything I should look out for)?

Lack of time :-( I wanted to improve the scripts a little bit more before committing. 1) The FindXXX.cmake files need to be written from scratch to work correctly (see comments in the bug). In the meantime there is e.g. the RunLoop (moved from WebKit2 to WebCore), which needs to be implemented in all CMake ports, to move the files in the build system too (if we don't want to commit a temporary solution). (I already begun with the WinCE stuff at bug 76781).

> Also, where can I get some tips on configuring and running the CMake build?

See how to build the EFL or WinCE. Mainly you only need to run "cmake /path/to/WebKitRoot -DPORT=WindowsApple". You can choose your toolchain via an additional "-G <generator>" argument.

(In reply to comment #10)
> I don't think we need to settle on one build system; even if we got down to just CMake, GYP, and XCode (for the Apple Mac port), that would be a big improvement.
IMHO only one build system isn't a bad idea, but still a very very long way. Reducing the existing ones and providing a good starting point for new ports (Blackberry uses CMake too) is good idea too. The CMake files are already shared across 3 ports, so the split of "common files" and "platform specific sources" has beed done there already. AFAIK this is possible with GYP too, but hasn't beed done yet.

[Brent Fulgham]

Thanks for working on this! I can't do a good job looking this over until tomorrow, but I did want to point out an older attempt (https://bugs.webkit.org/show_bug.cgi?id=53445) I made. It's already bit-rotted a little, but it gave a complete build a few weeks ago.

[Ashod Nakashian]

(In reply to comment #12)
> Thanks for working on this! I can't do a good job looking this over until tomorrow, but I did want to point out an older attempt (https://bugs.webkit.org/show_bug.cgi?id=53445) I made. It's already bit-rotted a little, but it gave a complete build a few weeks ago.

Thanks. Patrick brought it to my attention as well.

We'd like to get CMake updated and ready for prime time (bug 53455). But meanwhile, I'm arguing it'd be beneficial to the community (at least those working/would like to work with 2010) to have an instant 2010 support. This bug/patch does that with (IMHO) very little overhead, so the maintenance overhead is minimum.

If you could take a look, pdevenv is the actual patch, win-build-env.cmd (new script) is just for convenience (it sets up the build environment and prompts the user to pick a VS version if they have many, just run it and it's self-explanatory).

[Ashod Nakashian]

Created attachment 125520 [details]
Patch

[Ashod Nakashian]

The latest patch improves direct pdevenv invocation with correct cwd/path handling as well as temp-file cleanup and comments.

[Ashod Nakashian]

Any updates on this? Any hope of getting the patch committed, at least as a temp solution to vs2010 build support?

(Btw, the Trunk is no longer building on vs2010 due to code changes, try r106194.tar.bz2">http://builds.nightly.webkit.org/files/trunk/src/WebKit-r106194.tar.bz2 if you'd like to see the script in action on a successful build.)

[Brent Fulgham]

Comment on attachment 125520 [details]
Patch

Clearning flag, since this patch is no longer needed.

[Brent Fulgham]

Thanks for your work on this.  We've recently landed full VS2010 support, which renders these changes obsolete.

Please try the new project files out and let us know if you have any suggestions for improvement!

*** This bug has been marked as a duplicate of bug 106949 ***

[Brent Fulgham]

Comment on attachment 124896 [details]
VS2010 support scripts

Clearing flag

[Brent Fulgham]

Comment on attachment 125520 [details]
Patch

Clearing flag.