Summary: | Visual Studio 2010 toolchain support | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ashod Nakashian <ashodnakashian> | ||||||||||
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> | ||||||||||
Status: | RESOLVED DUPLICATE | ||||||||||||
Severity: | Normal | CC: | aroben, bfulgham, dpranke, eric, kihong.kwon, laszlo.gombos, paroga, vimff0, webkit.review.bot | ||||||||||
Priority: | P2 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Windows XP | ||||||||||||
Attachments: |
|
Description
Ashod Nakashian
2012-02-01 00:32:41 PST
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.
Created attachment 125493 [details]
Patch
Created attachment 125495 [details]
Patch
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. ;-) (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? (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. (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. (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. (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! 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. (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. 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. (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). Created attachment 125520 [details]
Patch
The latest patch improves direct pdevenv invocation with correct cwd/path handling as well as temp-file cleanup and comments. 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.) Comment on attachment 125520 [details]
Patch
Clearning flag, since this patch is no longer needed.
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 *** Comment on attachment 124896 [details]
VS2010 support scripts
Clearing flag
Comment on attachment 125520 [details]
Patch
Clearing flag.
|