Re: [webkit-dev] CMake as a build system?
On Fri, Apr 23, 2010 at 12:54 AM, Darin Fisher wrote: > > > On Tue, Apr 20, 2010 at 10:53 AM, Peter Kasting 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 > > 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?
Darin Fisher: > 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? I can post you my vcproj files, but they won't work on your machine, >From the CMake List: CMake generated project files can not be copied from machine to machine. There are rules to re-run CMake in the projects. Also, since CMake does system inspection, the new system may not have libraries and files in the same places as the original machine that CMake was run on, and the projects would be invalid. If you only want't to have a look at the project structure and how the generators are included I can send you my files. Otherwise you need install CMake. - 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 wrote: > On Fri, 23 Apr 2010 00:54:02 -0700, Darin Fisher > 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?
On Fri, 23 Apr 2010 00:54:02 -0700, Darin Fisher 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 Tue, Apr 20, 2010 at 10:53 AM, Peter Kasting 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 Wed, 21 Apr 2010 12:36:17 -0400, Marc-Antoine Ruel 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?
2010/4/20 > On Tue, 20 Apr 2010 10:53:55 -0700, Peter Kasting > 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 Tue, 20 Apr 2010 10:53:55 -0700, Peter Kasting 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?
On Tue, Apr 20, 2010 at 1:26 AM, Patrick Roland Gansterer 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?
Hi, 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. > 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. CMake generates some pre/post-project building steps to the vcprojs (or an additional project), where it runs a CMake script. 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? > 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. All dependencies are generated from CMake too (if declared correctly) and the "global namespace" isn't a real problem IMHO. > 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). Is there any demand for such a feature? Why you can't distribute the CMake file only? > 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). Supported since 2.6: http://www.cmake.org/Wiki/CMake_Cross_Compiling. - 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?
Actually it's fairly current (it was April 2, sure seemed like it was a long time ago, though I have been out with the plague...). That being said, it was based on stale knowledge of the state of cmake, which I sure has progressed since I looked at it over a year ago. My understanding is some things mentioned in this thread like absolute paths in cmake generated projects which were a concern at the time, are no longer an issue. #1 on that list really was the clincher for Chromium (which may not be as strong a motive for Webkit). It took us an exceedingly long time to shake out all the ramifications of the switch. As recently as a month ago, I came across some corner of the locales grd file handling that had left over use of pre-gyp tricks which continued to work for official builds because we never took out old buildbot magic. Had we not been able to transition windows gradually, I suspect a lot of the same nightmare bucket bailing of the aborted scons transition might have repeated themselves. Interestingly (from Bill Hoffman's reply), it sounds like this feature is now present in cmake. -BradN On Mon, Apr 19, 2010 at 10:43 PM, Peter Kasting wrote: > On Mon, Apr 19, 2010 at 10:38 PM, Bradley Nelson wrote: > >> 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 Mon, Apr 19, 2010 at 10:38 PM, Bradley Nelson wrote: > 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?
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 availabili
Re: [webkit-dev] CMake as a build system?
On 2010-04-17 at 03:58:17 [+0200], Bill Hoffman wrote: > On Fri, Apr 16, 2010 at 9:45 PM, Maciej Stachowiak 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 Not that I think this would be a major concern for anyone, but Haiku also has a pretty up2date CMake port. ;-) A unified build system would be great. Not only because it reduces work when adding or removing files, but also with regards to what part of the codebase gets compiled with which defines. If a port gets that wrong, all sorts of weird things can happen with objects having different size at different places in the code, and it's not exactly easy to become aquainted with the existing build systems quickly and feel confident. >From the one time I had to work with CMake, my colleges who wrote the CMake files were not so happy with the language, but after a few iterations, they managed to produce relatively clean build files. Many of us used QtCreator as the IDE and it's definitely not so nice when you have to add or remove files, since it requires quite a few extra steps possibly including restarting the IDE (at least with that version of QtCreator) until it finally picked up the changes in the project files. However, it might still be worth it. After all, people who currently enjoy an easy way to add files in their IDE will have to adapt the other build systems eventually. With CMake it would be the other way around, but perhaps with less potential to break things. Best regards, -Stephan ___ 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
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 > 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?
On Fri, Apr 16, 2010 at 10:04 PM, Adam Treat 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 Fri, Apr 16, 2010 at 10:10 PM, Marc-Antoine Ruel 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. -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?
> > 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?
2010/4/16 Marc-Antoine Ruel > 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 > > 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. > :) > ... and deprecate the prior build system! > > Not that my opinion counts at all. > > -- > M-A > -- 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 Apr 16, 2010, at 6:58 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 9:45 PM, Maciej Stachowiak 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. 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. All I'm saying is that it's not *currently* installed out of the box on Mac OS X. 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 So by "installed" we're just talking about the fact that it's an executable, not a script? 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?
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 > 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?
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?
On Fri, Apr 16, 2010 at 9:57 PM, Nico Weber 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 Fri, Apr 16, 2010 at 9:45 PM, Maciej Stachowiak 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?
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 wrote: > > On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote: > >> On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting >> wrote: >>> >>> On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak 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 Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote: On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting wrote: On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak 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?
On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting wrote: > On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak 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 Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak 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 Apr 16, 2010, at 3:25 PM, Adam Treat wrote: 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. 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.) 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 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?
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 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=8Ut9o4OdSC0&feature=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?
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 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=8Ut9o4OdSC0&feature=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 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=8Ut9o4OdSC0&feature=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
