Re: [webkit-dev] CMake as a build system?
On Fri, Apr 23, 2010 at 12:54 AM, Darin Fisher da...@chromium.org wrote: On Tue, Apr 20, 2010 at 10:53 AM, Peter Kasting pkast...@google.comwrote: On Tue, Apr 20, 2010 at 1:26 AM, Patrick Roland Gansterer par...@paroga.com wrote: Bradley Nelson: 1. Ability to incrementally transition on Windows. It took us about 6 months to switch fully to gyp. Previous attempts to move to scons had taken a long time and failed, due to the requirement to transition while in flight. For a substantial period of time, we had a hybrid of checked in vcproj and gyp generated CMake should be treated like a separate buildsystem like qmake or gyp during a possible switch. The point was that we wanted to be able to switch over in a gradual fashion, not by constructing a complete, functional parallel build system and then throwing the switch. If you take a look in the current vcprojs you can't understand them more easy than compared to CMake IMHO. Anyway: How often do you look at these settings? I use the IDE only for writing code and debugging. I do all my buildsystem changes directly in the CMake files. If i see the source files in the IDE I'm already happy. Do you have other requirements? AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio to correctly understand dependencies itself so that incremental builds from inside the IDE (which is where most Windows Chromium developers do their builds) work correctly and are as fast as possible (e.g. the null build should take close to zero time and not have to rerun steps or relink executables). Indeed. It also allows features like Ctrl+F7 (compile only the current source file) to work. A number of other common IDE features are lost if you use a makefile based vcproj. GYP nicely preserves all of those great IDE features, which to me is one of the main selling points as an end-user. -Darin Please disregard my comments above. Thanks to Patrick for showing me that CMake does indeed generate vcproj files that preserve this degree of integration with the IDE. GYP and CMake appear to have that in common. -Darin PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Tue, Apr 20, 2010 at 10:53 AM, Peter Kasting pkast...@google.com wrote: On Tue, Apr 20, 2010 at 1:26 AM, Patrick Roland Gansterer par...@paroga.com wrote: Bradley Nelson: 1. Ability to incrementally transition on Windows. It took us about 6 months to switch fully to gyp. Previous attempts to move to scons had taken a long time and failed, due to the requirement to transition while in flight. For a substantial period of time, we had a hybrid of checked in vcproj and gyp generated CMake should be treated like a separate buildsystem like qmake or gyp during a possible switch. The point was that we wanted to be able to switch over in a gradual fashion, not by constructing a complete, functional parallel build system and then throwing the switch. If you take a look in the current vcprojs you can't understand them more easy than compared to CMake IMHO. Anyway: How often do you look at these settings? I use the IDE only for writing code and debugging. I do all my buildsystem changes directly in the CMake files. If i see the source files in the IDE I'm already happy. Do you have other requirements? AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio to correctly understand dependencies itself so that incremental builds from inside the IDE (which is where most Windows Chromium developers do their builds) work correctly and are as fast as possible (e.g. the null build should take close to zero time and not have to rerun steps or relink executables). Indeed. It also allows features like Ctrl+F7 (compile only the current source file) to work. A number of other common IDE features are lost if you use a makefile based vcproj. GYP nicely preserves all of those great IDE features, which to me is one of the main selling points as an end-user. -Darin PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, 23 Apr 2010 00:54:02 -0700, Darin Fisher da...@chromium.org wrote: Indeed. It also allows features like Ctrl+F7 (compile only the current source file) to work. A number of other common IDE features are lost if you use a makefile based vcproj. GYP nicely preserves all of those great IDE features, which to me is one of the main selling points as an end-user. Did you tried my CMake example for the JSC executable? You can find it at https://bugs.webkit.org/show_bug.cgi?id=37945. I think that it show the CMake VisualStudio integration very good: You can even compile one of the generator script (e.g. for the hashtables) and all files with dependencies will rebuild too. Maybe you can tell me what is missing in the generated vsproj, so I can look at it and improve the CMakeLists.txt? - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 23, 2010 at 1:44 AM, Patrick Roland Gansterer par...@paroga.com wrote: On Fri, 23 Apr 2010 00:54:02 -0700, Darin Fisher da...@chromium.org wrote: Indeed. It also allows features like Ctrl+F7 (compile only the current source file) to work. A number of other common IDE features are lost if you use a makefile based vcproj. GYP nicely preserves all of those great IDE features, which to me is one of the main selling points as an end-user. Did you tried my CMake example for the JSC executable? You can find it at https://bugs.webkit.org/show_bug.cgi?id=37945. I think that it show the CMake VisualStudio integration very good: You can even compile one of the generator script (e.g. for the hashtables) and all files with dependencies will rebuild too. Maybe you can tell me what is missing in the generated vsproj, so I can look at it and improve the CMakeLists.txt? - Patrick Sorry, no I have not had the chance to test your patch. Since I'm not setup to run cmake, could you perhaps post the generated vcproj file? Thanks, -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
2010/4/20 par...@paroga.com On Tue, 20 Apr 2010 10:53:55 -0700, Peter Kasting pkast...@google.com wrote: AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio to correctly understand dependencies itself so that incremental builds from inside the IDE (which is where most Windows Chromium developers do their builds) work correctly and are as fast as possible (e.g. the null build should take close to zero time and not have to rerun steps or relink executables). I have an other big project running with CMake, but I didn't see such a problem. When you declare the correct dependencies CMake does a nerly perfect job IMHO. No rebuild time when nothing changed and no outdated objectfiles. Are the sources under an open source license? I'd like to take a look if so. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Wed, 21 Apr 2010 12:36:17 -0400, Marc-Antoine Ruel mar...@chromium.org wrote: Are the sources under an open source license? I'd like to take a look if so. I'm sorry, they are closed source. :-( But I have working CMake files for JSC on Windows already. I'd like to clean them up an try to get them run on other platform too before I post a patch at bugs.webkit.org. If you can't wait, I can send you my current files. You can see there for example how the the additional build steps like bison, hashtable generation, ... work. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Tue, Apr 20, 2010 at 1:26 AM, Patrick Roland Gansterer par...@paroga.com wrote: Bradley Nelson: 1. Ability to incrementally transition on Windows. It took us about 6 months to switch fully to gyp. Previous attempts to move to scons had taken a long time and failed, due to the requirement to transition while in flight. For a substantial period of time, we had a hybrid of checked in vcproj and gyp generated CMake should be treated like a separate buildsystem like qmake or gyp during a possible switch. The point was that we wanted to be able to switch over in a gradual fashion, not by constructing a complete, functional parallel build system and then throwing the switch. If you take a look in the current vcprojs you can't understand them more easy than compared to CMake IMHO. Anyway: How often do you look at these settings? I use the IDE only for writing code and debugging. I do all my buildsystem changes directly in the CMake files. If i see the source files in the IDE I'm already happy. Do you have other requirements? AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio to correctly understand dependencies itself so that incremental builds from inside the IDE (which is where most Windows Chromium developers do their builds) work correctly and are as fast as possible (e.g. the null build should take close to zero time and not have to rerun steps or relink executables). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Tue, 20 Apr 2010 10:53:55 -0700, Peter Kasting pkast...@google.com wrote: AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio to correctly understand dependencies itself so that incremental builds from inside the IDE (which is where most Windows Chromium developers do their builds) work correctly and are as fast as possible (e.g. the null build should take close to zero time and not have to rerun steps or relink executables). I have an other big project running with CMake, but I didn't see such a problem. When you declare the correct dependencies CMake does a nerly perfect job IMHO. No rebuild time when nothing changed and no outdated objectfiles. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Here's the innards of an email with a laundry list of stuff I came up with a while back on the gyp-developers list in response to Mike Craddick regarding what motivated gyp's development, since we were aware of cmake at the time (we'd even started a speculative port): I did an exploratory port of portions of Chromium to cmake (I think I got as far as net, base, sandbox, and part of webkit). There were a number of motivations, not all of which would apply to other projects. Also, some of the design of gyp was informed by experience at Google with large projects built wholly from source, leading to features absent from cmake, but not strictly required for Chromium. 1. Ability to incrementally transition on Windows. It took us about 6 months to switch fully to gyp. Previous attempts to move to scons had taken a long time and failed, due to the requirement to transition while in flight. For a substantial period of time, we had a hybrid of checked in vcproj and gyp generated vcproj. To this day we still have a good number of GUIDs pinned in the gyp files, because different parts of our release pipeline have leftover assumptions regarding manipulating the raw sln/vcprojs. This transition occurred from the bottom up, largely because modules like base were easier to convert, and had a lower churn rate. During early stages of the transition, the majority of the team wasn't even aware they were using gyp, as it integrated into their existing workflow, and only affected modules that had been converted. 2. Generation of a more 'normal' vcproj file. Gyp attempts, particularly on Windows, to generate vcprojs which resemble hand generated projects. It doesn't generate any Makefile type projects, but instead produces msvs Custom Build Steps and Custom Build Rules. This makes the resulting projects easier to understand from the IDE and avoids parts of the IDE that simply don't function correctly if you use Makefile projects. Our early hope with gyp was to support the least common denominator of features present in each of the platform specific project file formats, rather than falling back on generated Makefiles/shell scripts to emulate some common abstraction. CMake by comparison makes a good faith attempt to use native project features, but falls back on generated scripts in order to preserve the same semantics on each platforms. 3. Abstraction on the level of project settings, rather than command line flags. In gyp's syntax you can add nearly any option present in a hand generated xcode/vcproj file. This allows you to use abstractions built into the IDEs rather than reverse engineering them possibly incorrectly for things like: manifest generation, precompiled headers, bundle generation. When somebody wants to use a particular menu option from msvs, I'm able to do a web search on the name of the setting from the IDE and provide them with a gyp stanza that does the equivalent. In many cases, not all project file constructs correspond to command line flags. 4. Strong notion of module public/private interface. Gyp allows targets to publish a set of direct_dependent_settings, specifying things like include_dirs, defines, platforms specific settings, etc. This means that when module A depends on module B, it automatically acquires the right build settings without module A being filled with assumptions/knowledge of exactly how module B is built. Additionally, all of the transitive dependencies of module B are pulled in. This avoids their being a single top level view of the project, rather each gyp file expresses knowledge about its immediate neighbors. This keep local knowledge local. CMake effectively has a large shared global namespace. 5. Cross platform generation. CMake is not able to generate all project files on all platforms. For example xcode projects cannot be generated from windows (cmake uses mac specific libraries to do project generation). This means that for instance generating a tarball containing pregenerated projects for all platforms is hard with Cmake (requires distribution to several machine types). 6. Gyp has rudimentary cross compile support. Currently we've added enough functionality to gyp to support x86 - arm cross compiles. Last I checked this functionality wasn't present in cmake. (This occurred later). That being said there are a number of drawbacks currently to gyp: 1. Because platform specific settings are expressed at the project file level (rather than the command line level). Settings which might otherwise be shared in common between platforms (flags to gcc on mac/linux), end up being repeated twice. Though in fairness there is actually less sharing here than you'd think. include_dirs and defines actually represent 90% of what can be typically shared. 2. CMake may be more mature, having been applied to a broader range of projects. There a number of 'tool modules' for cmake, which are shared in a common community. 3. gyp currently makes some nasty assumptions about the
Re: [webkit-dev] CMake as a build system?
On Mon, Apr 19, 2010 at 10:38 PM, Bradley Nelson bradnel...@google.comwrote: Here's the innards of an email with a laundry list of stuff I came up with a while back on the gyp-developers list in response to Mike Craddick regarding what motivated gyp's development, since we were aware of cmake at the time (we'd even started a speculative port). Thanks Bradley. Is any of that old email known to be out-of-date/misleading now? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote: Hi, Adam Treat (tr...@kde.org) suggested that I join this list to talk about CMake as an option for a unified cross platform build solution. My name is Bill Hoffman. I am the lead CMake developer. My company Kitware created and supports CMake. I think CMake would have a lot to offer the WebKit developers. If you are not familiar with CMake, I did a google tech talk in December which can be found here: http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata Another article about how KDE switched to CMake can be found here: Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/ If you are interested in moving to CMake, I would be interested in helping. If you have any questions about CMake, fire away! Thanks. -Bill I asked Bill to introduce himself here because I think CMake represents the best hope for WebKit to find a way out of the current build system proliferation we are experiencing. Of the meta-buildsystems in existence I think CMake is by far the most powerful and mature. CMake is by far the most widespread and supported. It is already used successfully by Open Source projects of a comparable scope to WebKit and with similar cross-platform needs: LLVM, KDE, Boost. I know that WebKit already has GYP and QMake meta-buildsystems, but to my knowledge both are inferior to CMake. In fact, I do not think CMake is lacking in any important way to the features of GYP. What's more, the WebKit project has already had a CMake based buildsystem. This is what the 'Unity' nascent QtWebkit port used originally. I think we should re-introduce it and seriously consider using CMake as a cross-platform solution to our build system proliferation issues. I highly encourage you all to view the google tech talk above as it gives a great introduction to CMake. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
I don't see this as a decision needing pre-approval. This is a decision needing code. No one has tried to make Mac, Win, or other ports use a common system yet. Obviously converting them in the end requires buy-in from those ports. But producing a demo doesn't/shouldn't. I eventually plan to look at this task. When I do, I'll take a peek at CMake. Someone just needs to sit down and build something. Then we can make an informed decision. -eric On Fri, Apr 16, 2010 at 2:29 PM, Adam Treat tr...@kde.org wrote: On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote: Hi, Adam Treat (tr...@kde.org) suggested that I join this list to talk about CMake as an option for a unified cross platform build solution. My name is Bill Hoffman. I am the lead CMake developer. My company Kitware created and supports CMake. I think CMake would have a lot to offer the WebKit developers. If you are not familiar with CMake, I did a google tech talk in December which can be found here: http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata Another article about how KDE switched to CMake can be found here: Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/ If you are interested in moving to CMake, I would be interested in helping. If you have any questions about CMake, fire away! Thanks. -Bill I asked Bill to introduce himself here because I think CMake represents the best hope for WebKit to find a way out of the current build system proliferation we are experiencing. Of the meta-buildsystems in existence I think CMake is by far the most powerful and mature. CMake is by far the most widespread and supported. It is already used successfully by Open Source projects of a comparable scope to WebKit and with similar cross-platform needs: LLVM, KDE, Boost. I know that WebKit already has GYP and QMake meta-buildsystems, but to my knowledge both are inferior to CMake. In fact, I do not think CMake is lacking in any important way to the features of GYP. What's more, the WebKit project has already had a CMake based buildsystem. This is what the 'Unity' nascent QtWebkit port used originally. I think we should re-introduce it and seriously consider using CMake as a cross-platform solution to our build system proliferation issues. I highly encourage you all to view the google tech talk above as it gives a great introduction to CMake. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Sure. Having Bill's and Kitware's help will hopefully make it easier to produce such a demo using CMake. I pledge to help. We can start with this: http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853 Cheers, Adam On Friday 16 April 2010 05:34:45 pm Eric Seidel wrote: I don't see this as a decision needing pre-approval. This is a decision needing code. No one has tried to make Mac, Win, or other ports use a common system yet. Obviously converting them in the end requires buy-in from those ports. But producing a demo doesn't/shouldn't. I eventually plan to look at this task. When I do, I'll take a peek at CMake. Someone just needs to sit down and build something. Then we can make an informed decision. -eric On Fri, Apr 16, 2010 at 2:29 PM, Adam Treat tr...@kde.org wrote: On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote: Hi, Adam Treat (tr...@kde.org) suggested that I join this list to talk about CMake as an option for a unified cross platform build solution. My name is Bill Hoffman. I am the lead CMake developer. My company Kitware created and supports CMake. I think CMake would have a lot to offer the WebKit developers. If you are not familiar with CMake, I did a google tech talk in December which can be found here: http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata Another article about how KDE switched to CMake can be found here: Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/ If you are interested in moving to CMake, I would be interested in helping. If you have any questions about CMake, fire away! Thanks. -Bill I asked Bill to introduce himself here because I think CMake represents the best hope for WebKit to find a way out of the current build system proliferation we are experiencing. Of the meta-buildsystems in existence I think CMake is by far the most powerful and mature. CMake is by far the most widespread and supported. It is already used successfully by Open Source projects of a comparable scope to WebKit and with similar cross-platform needs: LLVM, KDE, Boost. I know that WebKit already has GYP and QMake meta-buildsystems, but to my knowledge both are inferior to CMake. In fact, I do not think CMake is lacking in any important way to the features of GYP. What's more, the WebKit project has already had a CMake based buildsystem. This is what the 'Unity' nascent QtWebkit port used originally. I think we should re-introduce it and seriously consider using CMake as a cross-platform solution to our build system proliferation issues. I highly encourage you all to view the google tech talk above as it gives a great introduction to CMake. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Apr 16, 2010, at 2:45 PM, Adam Treat wrote: Sure. Having Bill's and Kitware's help will hopefully make it easier to produce such a demo using CMake. I pledge to help. We can start with this: http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853 Can CMake generate native Xcode and Visual Studio project files? There are some people who consider it important to be able to edit, build and debug in the IDE. Can it handle generated sources well? I think those are the two toughest problems for any candidate unified build system. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Friday 16 April 2010 06:21:39 pm Maciej Stachowiak wrote: On Apr 16, 2010, at 2:45 PM, Adam Treat wrote: Sure. Having Bill's and Kitware's help will hopefully make it easier to produce such a demo using CMake. I pledge to help. We can start with this: http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853 Can CMake generate native Xcode and Visual Studio project files? There are some people who consider it important to be able to edit, build and debug in the IDE. Can it handle generated sources well? It was designed to do precisely that :) Bill can speak to this, but the google tech talk gives a great overview. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) CCing a couple people involved if they wish to answer. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting pkast...@google.com wrote: On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) I belive I can answer that. During my talk at google, I met with with Mark Mentovai and talked to him about Gyp and CMake. The main thing that he was trying to avoid was the requirement that CMake be installed for the build. That is true, CMake does have to be installed. However, CMake is installed on more an more systems. The cmake.org site has about 2K downloads per day, and most linux distros include CMake. With KDE using CMake, it has become pretty easy to get. Apple is also using CMake for the LLVM project, so it should be installed and accepted at Apple. I worked with Doug Gregor of the LLVM team to help him convince the Apple testing folks to allow for CMake to be installed. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting pkast...@google.com wrote: On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) I belive I can answer that. During my talk at google, I met with with Mark Mentovai and talked to him about Gyp and CMake. The main thing that he was trying to avoid was the requirement that CMake be installed for the build. That is true, CMake does have to be installed. However, CMake is installed on more an more systems. The cmake.org site has about 2K downloads per day, and most linux distros include CMake. With KDE using CMake, it has become pretty easy to get. Apple is also using CMake for the LLVM project, so it should be installed and accepted at Apple. I worked with Doug Gregor of the LLVM team to help him convince the Apple testing folks to allow for CMake to be installed. FWIW, I don't have CMake installed, and I have everything a typical Apple developer would have and then some. I'm running SnowLeopard and the latest Xcode. CMake is also not installed by default on Windows and I am not sure if it comes with the cygwin distribution we use. When you say installed, does that mean it *has* to be in some system location? Could it be installed somewhere in the WebKit build tree? Our scripts download certain needed tools and libraries by default, so at least from the WebKit POV this is not necessarily a showstopper. Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? And finally, I'd still like to hear from the Chromium folks whether there were any other issues. This one seems fairly minor. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
This is from an earlier thread on this issue on webkit-dev: We also considered CMake, and had it demonstrably working for some of our smaller projects as well. Unfortunately, transitioning to CMake would have required moving everything over at once, without allowing for some existing projects to be maintained by hand during a transition period. CMake-generated files contain absolute paths, so a .tar or .zip of the source tree could not be primed with CMake output, complicating the bootstrapping process for new contributors. A less significant factor was that CMake introduced an additional binary build prerequisite, which would have had to have been installed everywhere. Python is already a prerequisite for Chromium, so a Python tool was easier to deploy. Nico (I'm not involved with gyp at all, I just remembered that old thread) On Fri, Apr 16, 2010 at 6:45 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting pkast...@google.com wrote: On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak m...@apple.com wrote: I'm curious if the Chromium folks who created Gyp had any specific reason that they ruled out CMake as an option. (I have heard that it was considered and rejected.) I belive I can answer that. During my talk at google, I met with with Mark Mentovai and talked to him about Gyp and CMake. The main thing that he was trying to avoid was the requirement that CMake be installed for the build. That is true, CMake does have to be installed. However, CMake is installed on more an more systems. The cmake.org site has about 2K downloads per day, and most linux distros include CMake. With KDE using CMake, it has become pretty easy to get. Apple is also using CMake for the LLVM project, so it should be installed and accepted at Apple. I worked with Doug Gregor of the LLVM team to help him convince the Apple testing folks to allow for CMake to be installed. FWIW, I don't have CMake installed, and I have everything a typical Apple developer would have and then some. I'm running SnowLeopard and the latest Xcode. CMake is also not installed by default on Windows and I am not sure if it comes with the cygwin distribution we use. When you say installed, does that mean it *has* to be in some system location? Could it be installed somewhere in the WebKit build tree? Our scripts download certain needed tools and libraries by default, so at least from the WebKit POV this is not necessarily a showstopper. Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? And finally, I'd still like to hear from the Chromium folks whether there were any other issues. This one seems fairly minor. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 9:45 PM, Maciej Stachowiak m...@apple.com wrote: FWIW, I don't have CMake installed, and I have everything a typical Apple developer would have and then some. I'm running SnowLeopard and the latest Xcode. CMake is also not installed by default on Windows and I am not sure if it comes with the cygwin distribution we use. It can come with cygwin, and nothing is installed on Windows by default, not even the compiler... Macports has CMake, and of course we have binaries at cmake.org. When you say installed, does that mean it *has* to be in some system location? Could it be installed somewhere in the WebKit build tree? Our scripts download certain needed tools and libraries by default, so at least from the WebKit POV this is not necessarily a showstopper. It can be installed anywhere. There are binaries for all marjor OS's on www.cmake.org. It is setup to run from any directory, so you don't need root or anything to install. http://www.cmake.org/cmake/resources/software.html Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. And finally, I'd still like to hear from the Chromium folks whether there were any other issues. This one seems fairly minor. I would as well. :) -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 9:57 PM, Nico Weber tha...@chromium.org wrote: This is from an earlier thread on this issue on webkit-dev: We also considered CMake, and had it demonstrably working for some of our smaller projects as well. Unfortunately, transitioning to CMake would have required moving everything over at once, without allowing for some existing projects to be maintained by hand during a transition period. CMake-generated files contain absolute paths, so a .tar or .zip of the source tree could not be primed with CMake output, complicating the bootstrapping process for new contributors. A less significant factor was that CMake introduced an additional binary build prerequisite, which would have had to have been installed everywhere. Python is already a prerequisite for Chromium, so a Python tool was easier to deploy. I think you could do it part way. CMake has a new feature called external_project that allows you to download/configure/build packages using any build system. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote: Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. To be clear, it just has to be in the path, right? Which I think could be managed ;) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Thanks Nico for digging up the archive. As I said in the other thread, the people at the session mostly looked about reducing the number of build system, not forcing anyone to use any tool. If some teams wants to switch to CMake, prefect as long as the number of build tool reduces. Nobody seemed willing to switch to qtmake. Nobody at the meeting advocated for CMake. I don't have first-hand experience about CMake but from I only heard midly negative comments. The generated xcodeproj and vcproj are far from 'native' and from f2f discussion, at least one llvm guy isn't happy about CMake and would rather move it off. The 'native' IDE feel was very high in our priority list, especially in XCode in fact. 2010/4/16 Adam Treat tr...@kde.org On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote: Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. To be clear, it just has to be in the path, right? Which I think could be managed ;) I don't know if anyone really cares about the requirement of having another tool installed on the system or not as an hinderance, I don't mind. So in the end, if some team want to switch to CMake, just check-in stuff. :) Not that my opinion counts at all. -- M-A ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
We can make binaries available through a convenient download script (possibly one that gets a source drop and builds it) if we have to. In fact, when WebKit first switched to Subversion, for a while you had to get your own copy to even check out the tree. Sounds good. All I'm saying is that it's not *currently* installed out of the box on Mac OS X. Sure. So by installed we're just talking about the fact that it's an executable, not a script? Yes, it is a binary. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Fri, Apr 16, 2010 at 10:04 PM, Adam Treat tr...@kde.org wrote: On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote: Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. To be clear, it just has to be in the path, right? Which I think could be managed ;) No, it is much more than the path. CMake needs to be around during the build, and at configure time. It does system introspection, also with the makefiles it includes a depend generator. So, to be clear, you have to install and run CMake on the machine where you are building the software. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Apr 16, 2010, at 7:17 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 10:10 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Thanks Nico for digging up the archive. As I said in the other thread, the people at the session mostly looked about reducing the number of build system, not forcing anyone to use any tool. If some teams wants to switch to CMake, prefect as long as the number of build tool reduces. Nobody seemed willing to switch to qtmake. Nobody at the meeting advocated for CMake. I don't have first-hand experience about CMake but from I only heard midly negative comments. The generated xcodeproj and vcproj are far from 'native' and from f2f discussion, at least one llvm guy isn't happy about CMake and would rather move it off. The 'native' IDE feel was very high in our priority list, especially in XCode in fact. It is as native as we can make it. However, we do call cmake during the build at some points, to overcome shortfalls of the build tool. Also, to re-run cmake if any of the input files change. Also, basic system commands like cp can be done with cmake -E copy_file so it is portable. Calling cmake during the build would likely be a showstopper for the Mac port. As far as I know, Apple's build farm does not have CMake installed (at least not on older build trains). And it's not easy to convince the build engineers to install custom build tools. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Calling cmake during the build would likely be a showstopper for the Mac port. As far as I know, Apple's build farm does not have CMake installed (at least not on older build trains). And it's not easy to convince the build engineers to install custom build tools. I am told they have it now for LLVM. But, I do not work for Apple, so I can not verify that. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
