Re: [webkit-dev] Buildsystem cleanup
Hi Patrick, We haven’t looked at it, but we’ve decided we are interested in making it work for us. However, we will still need to keep the VS2010 project files in our tree for some undetermined amount of time. If you want to start adding a cmake support windows support for the AppleWin port to the tree, that’d be great! Unfortunately, we’ll have to wait for some time before fully adopting cmake into our system. Feel free to ask Brent and me for help at any point though! Thanks! Roger On Jul 12, 2013, at 5:07 AM, Patrick Gansterer par...@paroga.com wrote: Hi Roger, did you have some time to look at my example in the meantime? -- Patrick Am 11.04.2013 um 00:30 schrieb Roger Fong: Hi Patrick, A few questions I have about the CMake system, being someone who's never used it before. -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided. Can we still maintain that through CMake easily? -How does CMake handle different build targets. Would I have to open up different project files per configuration? -If I'm understanding things correctly the main differences with using CMake would be: 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe). We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree. 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which. If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. Thanks, Roger On Apr 9, 2013, at 9:34 AM, Patrick Gansterer par...@paroga.com wrote: Hi, On Mon, 08 Apr 2013 18:10:29 -0700, Mark Rowe wrote: On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote: Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Sounds good. I pushed a quick dirty example to [1], which shows a possible solution for WTF and JavaScriptCore. You can test it with the following steps. The helper directory contains then all built files. * Create a directory helper * Copy all files from Source/cmake to helper/cmake * Copy all files (including the support libraries) from WebKitLibraries to helper/WebKitLibraries * Create an independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/WTF/wtf -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * You get a WTF.zip, which should be extracted in the directory helper * Create an additional independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/JavaScriptCore -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * Yout get a JavaScriptCore.zip with the DLL I would be great if someone can verify that this solution will work for the internal builds at Apple. If I get positive feedback I'll can implement this for WebCore and WebKit too. Is there someone who will review my patches for this? Do you think it's possible to directly switch to CMake at Apple instead of upstreaming the VS2010 files? IHMO the whole work can be done in a few days, if someone at Apple is willing to work with me on it. [1] https://github.com/paroga/webkit -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Hi Roger, did you have some time to look at my example in the meantime? -- Patrick Am 11.04.2013 um 00:30 schrieb Roger Fong: Hi Patrick, A few questions I have about the CMake system, being someone who's never used it before. -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided. Can we still maintain that through CMake easily? -How does CMake handle different build targets. Would I have to open up different project files per configuration? -If I'm understanding things correctly the main differences with using CMake would be: 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe). We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree. 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which. If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. Thanks, Roger On Apr 9, 2013, at 9:34 AM, Patrick Gansterer par...@paroga.com wrote: Hi, On Mon, 08 Apr 2013 18:10:29 -0700, Mark Rowe wrote: On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote: Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Sounds good. I pushed a quick dirty example to [1], which shows a possible solution for WTF and JavaScriptCore. You can test it with the following steps. The helper directory contains then all built files. * Create a directory helper * Copy all files from Source/cmake to helper/cmake * Copy all files (including the support libraries) from WebKitLibraries to helper/WebKitLibraries * Create an independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/WTF/wtf -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * You get a WTF.zip, which should be extracted in the directory helper * Create an additional independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/JavaScriptCore -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * Yout get a JavaScriptCore.zip with the DLL I would be great if someone can verify that this solution will work for the internal builds at Apple. If I get positive feedback I'll can implement this for WebCore and WebKit too. Is there someone who will review my patches for this? Do you think it's possible to directly switch to CMake at Apple instead of upstreaming the VS2010 files? IHMO the whole work can be done in a few days, if someone at Apple is willing to work with me on it. [1] https://github.com/paroga/webkit -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Buildsystem cleanup
I'm glad to see there is some interest in using CMake to build on windows. Using CMake has made working on Windows easier for me (thank you Patrick!)... somewhere on webkit.org there's a page about ideas for making life on windows easier and I think the CMake build system addresses a number of the concerns. Patrick uploaded a patch (https://bugs.webkit.org/show_bug.cgi?id=72816) that uses a strategy of separate CMake platforms for the Apple Windows build, for Windows Cairo, and for Windows CE. I think there's a lot of duplication in having 3 separate CMake platforms for Windows builds. I put another patch out there which creates a single PlatformWin. Build switches passed to CMake then generate the platform you want (Apple, WinCairo - in the future WinCE). I'm curious for those who are interested in CMake for Windows builds which approach they think makes more sense. Duplication but full isolation or no duplication but more opportunity to collide. Both patches are still works in progress. - Mark Salisbury ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Hi Patrick, A few questions I have about the CMake system, being someone who's never used it before. -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided. Can we still maintain that through CMake easily? -How does CMake handle different build targets. Would I have to open up different project files per configuration? -If I'm understanding things correctly the main differences with using CMake would be: 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe). We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree. 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which. If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. Thanks, Roger On Apr 9, 2013, at 9:34 AM, Patrick Gansterer par...@paroga.com wrote: Hi, On Mon, 08 Apr 2013 18:10:29 -0700, Mark Rowe wrote: On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote: Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Sounds good. I pushed a quick dirty example to [1], which shows a possible solution for WTF and JavaScriptCore. You can test it with the following steps. The helper directory contains then all built files. * Create a directory helper * Copy all files from Source/cmake to helper/cmake * Copy all files (including the support libraries) from WebKitLibraries to helper/WebKitLibraries * Create an independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/WTF/wtf -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * You get a WTF.zip, which should be extracted in the directory helper * Create an additional independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/JavaScriptCore -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * Yout get a JavaScriptCore.zip with the DLL I would be great if someone can verify that this solution will work for the internal builds at Apple. If I get positive feedback I'll can implement this for WebCore and WebKit too. Is there someone who will review my patches for this? Do you think it's possible to directly switch to CMake at Apple instead of upstreaming the VS2010 files? IHMO the whole work can be done in a few days, if someone at Apple is willing to work with me on it. [1] https://github.com/paroga/webkit -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Hi everyone: Sent from my iPhone On Apr 10, 2013, at 3:30 PM, Roger Fong roger_f...@apple.com wrote: 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. I think the enable/disable stuff we use for conditionally building WinCairo versus stock Apple would go away; ale generates project files with only the relevant items per build. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Yes, it's -G It allows choices between Xcode, Visual Studio 2006, VS2012, etc. ... move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. I can help with this now. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. Agreed! Patrick, can you expound a little on the abilities cmake apparently has for performing shell operations? I think you suggested at one point that some of the. Things we currently do with BASH and DOS shell scripts could be done by cmake. Can you elaborate on what kind of things? - Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
On Wed, Apr 10, 2013 at 3:30 PM, Roger Fong roger_f...@apple.com wrote: If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. We're going to try it out for WebKitGTK+ and that really just leaves QtWebKit on qmake [1]. Perhaps someday WebKit will only have two build systems. :) 1. There's also the Wx port, but they don't seem very interested in switching and it seems the build system is very low maintenance. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 11.04.2013 um 00:30 schrieb Roger Fong: Hi Patrick, A few questions I have about the CMake system, being someone who's never used it before. -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided. Can we still maintain that through CMake easily? The main idea in CMake is, that it does not know anything about Visual Studio sheets. This is required to use other generators as well (e.g. a -G Ninja). What you usually do with VS property sheets is done with CMake variables, where you store your compiler, linker or whatever flags. -How does CMake handle different build targets. Would I have to open up different project files per configuration? In the default configuration CMake has 4 configurations: Debug, Release, MinSizeRelease and RelWithDebInfo. This allows in 99% direct production builds out of Visual Studio. Makefile generators (including Ninja) do not have this configuration and instead expect a -DCMAKE_BUILD_TYPE=config when running CMake. If you need additional configurations (e.g. the current Production configs) the CMake-way is to do this with an additional CMake variable defined via command line. So if you want a production build you just add a -DBUILD_FOR_PRODUCTION=ON to the initial call to cmake. Then you can do stuff like if (BUILDFOR_PRODUCTION) list(APPEND LINNKER_FLAGS ...) endif () to get the job done. -If I'm understanding things correctly the main differences with using CMake would be: 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe). We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree. Importent is that you do not change the VS files any more. Only the CMake files should be changed then. CMake adds an additional project into the Visual Studio solution (ZERO_CHECK), which detects modified CMake files and runs cmake if something has changed. Since adding/removing a source files results in a change of the CMake file everything is done automatically. build-wekit has already support for CMake, so you only need to remove the VS code. :-) 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. You can do this in VS as well: You only need to open the CMakeLists.txt in Visual Studio and add i there. Pressing the build button then generates new VS project, as mentioned before. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which. -G does the job. You can also use Makefile based generators with no extra work. IMHO it would be great to use -G Ninja an the buildbots, since it has a much better output when you only see the command line (and it's faster). If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. Many thanks. Please let me know if you see additional problems so we can address them as soon as possible. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Please let me know when I can help somewhere. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. IMHO we can enforce new ports to use CMake already. Does anybody know if it's possible for the Qt port to switch to CMake? I know that QtWebKit is part of the Qt source distribution, which does not require CMake. Maybe somebody can tell me if the following would work for Qt: Use the CMake builds as e.g. EFL does at the moment and add an additional target for auto-generation of the qmake files. This qmake files then only have a list of header and source files, since code-generators (e.g. for IDL) are run by CMake. Am 11.04.2013 um 00:39 schrieb Brent Fulgham: On Apr 10, 2013, at 3:30 PM, Roger Fong roger_f...@apple.com wrote: 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we
Re: [webkit-dev] Buildsystem cleanup
Hi Patrick, On Apr 10, 2013, at 8:12 PM, Patrick Gansterer wrote: [snip] 1. There's also the Wx port, but they don't seem very interested in switching and it seems the build system is very low maintenance. There is still a patch at webkit.org/b/73100 for adding CMake files for Wx. The decision has already been made to remove wx from the tree (I need to whip up a patch when I have time…), so it probably isn't worth spending time on this. Regards, Kevin -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Hi, On Mon, 08 Apr 2013 18:10:29 -0700, Mark Rowe wrote: On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote: Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Sounds good. I pushed a quick dirty example to [1], which shows a possible solution for WTF and JavaScriptCore. You can test it with the following steps. The helper directory contains then all built files. * Create a directory helper * Copy all files from Source/cmake to helper/cmake * Copy all files (including the support libraries) from WebKitLibraries to helper/WebKitLibraries * Create an independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/WTF/wtf -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * You get a WTF.zip, which should be extracted in the directory helper * Create an additional independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/JavaScriptCore -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * Yout get a JavaScriptCore.zip with the DLL I would be great if someone can verify that this solution will work for the internal builds at Apple. If I get positive feedback I'll can implement this for WebCore and WebKit too. Is there someone who will review my patches for this? Do you think it's possible to directly switch to CMake at Apple instead of upstreaming the VS2010 files? IHMO the whole work can be done in a few days, if someone at Apple is willing to work with me on it. [1] https://github.com/paroga/webkit -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
What would it take to switch build-webkit, et al to the VS2010 build? (VS2010 does work manually though, if you run build-webkit at least once, let it fail since it can't find VS2005/VS2008, and then build it from the solution file) From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Roger Fong Sent: Monday, April 08, 2013 3:26 PM To: Patrick Gansterer Cc: WebKit Development Subject: Re: [webkit-dev] Buildsystem cleanup Unfortunately this would cause a lot of complication in our internal build setup that we currently don't really have the resources to deal with right now. It would be nice to unite all the build systems at some point in the future but we're going to push this one off for now. Also we're planning on getting rid of the VS2005 eventually. On Apr 7, 2013, at 6:47 PM, Patrick Gansterer par...@paroga.commailto:par...@paroga.com wrote: Hi, since the Chromium code is getting removed step by step I think that the GYP build system won't have a shiny future in the WebKit repository. In the GYP vs. CMake match CMake gets an additional point: There is no WebKit port working with GYP, but at least 3 with CMake. Accordantly to [1] GTK will give CMake a try too. Adopting the Mac port does not seam to be an easy task in the near future, because of the very specific build requirements. But what about the Windows ports? I updated the patch at [2] to work with a more recent revision. Are there any chances to use CMake instead of the VS solution files? At the moment it becomes even worst, since there are VS2005 and VS2010 files in the tree, which duplicated many files. The patch at [2] is only an initial example, since a complete implementation would require more changes in the code. If CMake becomes an option, I'm willing to provide an complete patch with all CMake files. -- Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024399.html [2] https://bugs.webkit.org/show_bug.cgi?id=72816 ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
I wasn’t aware that the build worked without a VS2010 pThreads build. I was running into issues because of the pThreads dll having embedded manifest problems earlier. Did you do anything special to circumvent that issue? It won’t take much to switch it over but the problem was originally that I couldn’t get it to build without a newer compile of the pthreads library. Thus we were waiting for the pthreads folks to release a newer pthreads dll before doing the switch over. Also, I believe Brent Fulgham may have modified build-webkit to set environment variables appropriately because the VS2010 solution uses different ones than the VS2005 solution. I just have those variables set permanently and just build directly from the solution file. (Need to update those build.webkit.org instructions) On Apr 8, 2013, at 1:13 PM, Justin Haygood justin.hayg...@reaktix.com wrote: What would it take to switch build-webkit, et al to the VS2010 build? (VS2010 does work manually though, if you run build-webkit at least once, let it fail since it can’t find VS2005/VS2008, and then build it from the solution file) From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Roger Fong Sent: Monday, April 08, 2013 3:26 PM To: Patrick Gansterer Cc: WebKit Development Subject: Re: [webkit-dev] Buildsystem cleanup Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. It would be nice to unite all the build systems at some point in the future but we’re going to push this one off for now. Also we’re planning on getting rid of the VS2005 eventually. On Apr 7, 2013, at 6:47 PM, Patrick Gansterer par...@paroga.com wrote: Hi, since the Chromium code is getting removed step by step I think that the GYP build system won't have a shiny future in the WebKit repository. In the GYP vs. CMake match CMake gets an additional point: There is no WebKit port working with GYP, but at least 3 with CMake. Accordantly to [1] GTK will give CMake a try too. Adopting the Mac port does not seam to be an easy task in the near future, because of the very specific build requirements. But what about the Windows ports? I updated the patch at [2] to work with a more recent revision. Are there any chances to use CMake instead of the VS solution files? At the moment it becomes even worst, since there are VS2005 and VS2010 files in the tree, which duplicated many files. The patch at [2] is only an initial example, since a complete implementation would require more changes in the code. If CMake becomes an option, I'm willing to provide an complete patch with all CMake files. -- Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024399.html [2] https://bugs.webkit.org/show_bug.cgi?id=72816 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? My last deeper discussion with aroben (!) is already a long time ago, but his answer was that beside installing CMake on the machines building the code, there is no real blocker. Is this still valid or was this never right. It would be nice to unite all the build systems at some point in the future but we’re going to push this one off for now. Yes, but we need to start at some point. Only dreaming about it is not enough. I'm willing to do the work, but I need at least some information. I don't want to do the work if it is not accepted as in https://bugs.webkit.org/show_bug.cgi?id=73100. Also we’re planning on getting rid of the VS2005 eventually. Eventually? How long do we want to maintain two VS versions in the tree? Am 08.04.2013 um 22:34 schrieb Roger Fong: I wasn’t aware that the build worked without a VS2010 pThreads build. I was running into issues because of the pThreads dll having embedded manifest problems earlier. Did you do anything special to circumvent that issue? I committed many patches to get rid of pthread as a whole on Windows in the past. Maybe I use a special flag which disables the remaining pthread calls on Windows. It won’t take much to switch it over but the problem was originally that I couldn’t get it to build without a newer compile of the pthreads library. Thus we were waiting for the pthreads folks to release a newer pthreads dll before doing the switch over. Why not just remove the remaining pthread calls on Windows (if there are) and disable USE(PTHREADS)? I'm willing to do the work here too, to get rid of pthreads on Windows. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote: Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? The biggest complicating factor is that when each project builds it only has access to its own source, and the built products from earlier projects. This was mentioned the last time you suggested switching to CMake for the Windows build: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
On Apr 8, 2013, at 3:44 PM, Patrick Gansterer par...@paroga.com wrote: I wasn’t aware that the build worked without a VS2010 pThreads build. I was running into issues because of the pThreads dll having embedded manifest problems earlier. Did you do anything special to circumvent that issue? I committed many patches to get rid of pthread as a whole on Windows in the past. Maybe I use a special flag which disables the remaining pthread calls on Windows. It won’t take much to switch it over but the problem was originally that I couldn’t get it to build without a newer compile of the pthreads library. Thus we were waiting for the pthreads folks to release a newer pthreads dll before doing the switch over. Why not just remove the remaining pthread calls on Windows (if there are) and disable USE(PTHREADS)? I'm willing to do the work here too, to get rid of pthreads on Windows. Regardless of the cmake issue, ^^ this seems like a valid and useful project. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 09.04.2013 um 00:58 schrieb Mark Rowe: On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote: Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? The biggest complicating factor is that when each project builds it only has access to its own source, and the built products from earlier projects. This was mentioned the last time you suggested switching to CMake for the Windows build: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html. I know the last thread, so please don't hurt me if I ask dumb questions, but how does it work at the moment? ;-) What is the root directory of a checkout? E.g. if I checkout only Source/JavaScriptCore how can I access the vsprops files from WebKitLibraries/win? Is there a checkout of this global files for the individual targets too? If there is a checkout of the whole tree for every target, how do you make sure that the files from the previous build are use (and not from the checkout)? Maybe someone can explain the details a little bit more, so I can understand the requirements? Beside this, is there a general problem with CMake for the Windows port? For the Mac port there is the problem, that CMake is not an executable provided by the system (maybe i can some time...). Since many other tools are require separate installation on Windows anyway there should be no problem in installing CMake too? -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
On 2013-04-08, at 17:16, Patrick Gansterer par...@paroga.com wrote: Am 09.04.2013 um 00:58 schrieb Mark Rowe: On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote: Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? The biggest complicating factor is that when each project builds it only has access to its own source, and the built products from earlier projects. This was mentioned the last time you suggested switching to CMake for the Windows build: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html. I know the last thread, so please don't hurt me if I ask dumb questions, but how does it work at the moment? ;-) What is the root directory of a checkout? E.g. if I checkout only Source/JavaScriptCore how can I access the vsprops files from WebKitLibraries/win? WebKitLibraries/win/tools is treated as its own project. It is built first so that the other WebKit projects can use the files that it installs. You can see a Makefile at WebKitLibraries/win/tools/WinTools.make that does the installation. Is there a checkout of this global files for the individual targets too? No. If there is a checkout of the whole tree for every target, how do you make sure that the files from the previous build are use (and not from the checkout)? Only a subset of the tree is available. For instance, when preparing to build JavaScriptCore the relevant source is fetched using “svn export https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The resulting directory is then provided to the build machine. Beside this, is there a general problem with CMake for the Windows port? For the Mac port there is the problem, that CMake is not an executable provided by the system (maybe i can some time...). Since many other tools are require separate installation on Windows anyway there should be no problem in installing CMake too? Making the CMake executable available shouldn’t be a problem. Do the projects generated by CMake suffer from the same problem with absolute paths as CMake’s Xcode projects? I’m not sure whether that would be a problem for us on Windows, but it’s good to understand any limitations ahead of time. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 09.04.2013 um 02:29 schrieb Mark Rowe: On 2013-04-08, at 17:16, Patrick Gansterer par...@paroga.com wrote: Am 09.04.2013 um 00:58 schrieb Mark Rowe: On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote: Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? The biggest complicating factor is that when each project builds it only has access to its own source, and the built products from earlier projects. This was mentioned the last time you suggested switching to CMake for the Windows build: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html. I know the last thread, so please don't hurt me if I ask dumb questions, but how does it work at the moment? ;-) What is the root directory of a checkout? E.g. if I checkout only Source/JavaScriptCore how can I access the vsprops files from WebKitLibraries/win? WebKitLibraries/win/tools is treated as its own project. It is built first so that the other WebKit projects can use the files that it installs. You can see a Makefile at WebKitLibraries/win/tools/WinTools.make that does the installation. So having an additional top level directory with all shares CMake files is possible? How are the ENABLE_* feature defines handled? Are they part of this files too? Is there a checkout of this global files for the individual targets too? No. But they are installed via a previous build, so mainly the same. ;-) If there is a checkout of the whole tree for every target, how do you make sure that the files from the previous build are use (and not from the checkout)? Only a subset of the tree is available. For instance, when preparing to build JavaScriptCore the relevant source is fetched using “svn export https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The resulting directory is then provided to the build machine. Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Beside this, is there a general problem with CMake for the Windows port? For the Mac port there is the problem, that CMake is not an executable provided by the system (maybe i can some time...). Since many other tools are require separate installation on Windows anyway there should be no problem in installing CMake too? Making the CMake executable available shouldn’t be a problem. Do the projects generated by CMake suffer from the same problem with absolute paths as CMake’s Xcode projects? I’m not sure whether that would be a problem for us on Windows, but it’s good to understand any limitations ahead of time. What is the concrete problem with the absolute paths? It's true that you can't copy a generated vcproj to an other location, but that shouldn't be required when you have installed CMake on that machine. And since the CMake executable is required by the generated build files (in the background for platform abstraction) it makes not much sense in a CMake workflow anyway. You usually just run cd build_dir cmake path/to/source cmake --build . and get all your files built. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote: Am 09.04.2013 um 02:29 schrieb Mark Rowe: On 2013-04-08, at 17:16, Patrick Gansterer par...@paroga.com wrote: Am 09.04.2013 um 00:58 schrieb Mark Rowe: On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote: Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? The biggest complicating factor is that when each project builds it only has access to its own source, and the built products from earlier projects. This was mentioned the last time you suggested switching to CMake for the Windows build: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html. I know the last thread, so please don't hurt me if I ask dumb questions, but how does it work at the moment? ;-) What is the root directory of a checkout? E.g. if I checkout only Source/JavaScriptCore how can I access the vsprops files from WebKitLibraries/win? WebKitLibraries/win/tools is treated as its own project. It is built first so that the other WebKit projects can use the files that it installs. You can see a Makefile at WebKitLibraries/win/tools/WinTools.make that does the installation. So having an additional top level directory with all shares CMake files is possible? It should be, yes. How are the ENABLE_* feature defines handled? Are they part of this files too? I think that’s what the WebKitLibraries/win/tools/vsprops/FeatureDefines* is about, yes. If there is a checkout of the whole tree for every target, how do you make sure that the files from the previous build are use (and not from the checkout)? Only a subset of the tree is available. For instance, when preparing to build JavaScriptCore the relevant source is fetched using “svn export https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The resulting directory is then provided to the build machine. Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Sounds good. Beside this, is there a general problem with CMake for the Windows port? For the Mac port there is the problem, that CMake is not an executable provided by the system (maybe i can some time...). Since many other tools are require separate installation on Windows anyway there should be no problem in installing CMake too? Making the CMake executable available shouldn’t be a problem. Do the projects generated by CMake suffer from the same problem with absolute paths as CMake’s Xcode projects? I’m not sure whether that would be a problem for us on Windows, but it’s good to understand any limitations ahead of time. What is the concrete problem with the absolute paths? It's true that you can't copy a generated vcproj to an other location, but that shouldn't be required when you have installed CMake on that machine. And since the CMake executable is required by the generated build files (in the background for platform abstraction) it makes not much sense in a CMake workflow anyway. You usually just run cd build_dir cmake path/to/source cmake --build . and get all your files built. I mentioned it because it's an obvious point that’s different than how our existing build systems work and so it has the potential to cause unexpected problems. I’m not aware of any actual issues that it will cause (beyond offending my sensibilities). - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Buildsystem cleanup
Hi, since the Chromium code is getting removed step by step I think that the GYP build system won't have a shiny future in the WebKit repository. In the GYP vs. CMake match CMake gets an additional point: There is no WebKit port working with GYP, but at least 3 with CMake. Accordantly to [1] GTK will give CMake a try too. Adopting the Mac port does not seam to be an easy task in the near future, because of the very specific build requirements. But what about the Windows ports? I updated the patch at [2] to work with a more recent revision. Are there any chances to use CMake instead of the VS solution files? At the moment it becomes even worst, since there are VS2005 and VS2010 files in the tree, which duplicated many files. The patch at [2] is only an initial example, since a complete implementation would require more changes in the code. If CMake becomes an option, I'm willing to provide an complete patch with all CMake files. -- Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024399.html [2] https://bugs.webkit.org/show_bug.cgi?id=72816 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
