On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke <dpra...@chromium.org> wrote:
> On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer <par...@paroga.com> > wrote: > > > > Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak: > > > > > > On Jan 31, 2013, at 1:56 AM, Patrick Gansterer <par...@paroga.com> > wrote: > > > > Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa: > > > > On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger <joc...@chromium.org> > > wrote: > >> > >> Another option is to add a webkit-patch command for modifying the build > >> files. That way, the syntax doesn't need to be overly human friendly. > There > >> was also some attempt to write a tool to add files automatically: > >> https://bugs.webkit.org/show_bug.cgi?id=61772 I would expect that > such a > >> tool becomes easier if it would only modify one source of truth and > >> generates all other artifacts such as Xcode projects from it. > > > > > > I don't want build file's syntax to be so human unfriendly that I need a > > tool for it. > > > > Often times, these syntax problems can be improved dramatically by simple > > changes. e.g. we had a similar discussion about TestExpectation syntax, > and > > I'm much happier with the new syntax even though the new syntax is > > functionally equivalent to the old one, and two syntaxes are very > similar. > > > > On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe <mr...@apple.com> wrote: > >> > >> I’ve experimented with this in the past and you’re right that it > shouldn’t > >> be particularly difficult to do. However, I suspect that the task would > be > >> similar in scope to defining an improved syntax for gyp. And if the > syntax > >> is the primary sticking point with gyp then it’d seem preferable to > tackle > >> initially. > > > > > > Yeah. In fact, we can just come up with whatever syntax we like and > convert > > it to the existing gyp format if the syntax was the biggest issue. > > > > > > Do we want to define the whole build system (including information how to > > invoke the generators) with the new system, or is a "simple" list for the > > input files sufficient? IMHO adding a new generator build step happens > very > > rarely. So maybe we can spit the "input file list" (mainly *.cpp and > *.idl) > > into new files. > > Then GYP and CMake can read them and generate the build system out of > them > > directly (like they to already today) instead of listing the files in the > > *.gpyi and *.cmake. This might work for other systems like qmake too. > > For XCode we can maybe have a "template XCode project" and generate the > > "work XCode project" with a script. This script then only need to fill in > > the files from the "input file list" into the "template XCode project". > > Defining the feature flags can be done like Maciej suggested with > "Port.h" > > files. > > > > > > I think it would be better to adapt an existing meta build system to our > > needs than to make one from scratch, unless we find that completely > > impractical. > > > > In particular, gyp and cmake both know how to handle generated sources, > and > > while it may not be super common to make a new type of generated source, > > it's bad for hackability of the project of doing so is super hard. We > get a > > lot of hackability benefits from using various kinds of generated > sources, > > many first introduced in the days when we had a lot fewer build systems. > So > > in my mind, they are already ahead of a hypothetical "simple" system. > > > > > > Do you want to kick the requirements of the smaller ports from trunk or > do > > you think that e.g. a qmake generate for GYP makes sense? > > AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system, > > where CMake/GYP is not an option. > > > > It could certainly make sense for us to add Autotools and Qmake > generators to GYP; I'm less certain if a CMake generator makes much > sense, but I haven't thought about it as much. I'm not super familiar > with any of these three tools, so I could be dead wrong. > I think making Autotools and Qmake use GYP will be a huge win even if we couldn't make Xcodeproj and CMake use GYP at the end. Having GYP + CMake + Xcodeproj is much better than having Autotools and Qmake on top of that. I don't think we need to necessarily unify all build systems. Reducing the number of build systems is a worthwhile goal on its own merit. - R. Niwa
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
