See https://bugs.webkit.org/show_bug.cgi?id=61773 https://bugs.webkit.org/show_bug.cgi?id=64149
On Thu, Jan 31, 2013 at 12:36 PM, Nico Weber <tha...@chromium.org> wrote: > This is a lovely discussion to have every now and then :-) > > Maybe the file add/move/delete tool that someone wrote could land > without xcode support for now? Then the pain of moving files is > reduced to two systems (xcode and everyone else), and that's something > that's at least tractable. > > Nico > > 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 > - R. 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 completely agree that creating a new meta meta build system isn't a > good > >> idea, but sharing the common parts (which reduce the daily productivity) > >> might be a step in the right direction. Using simple text files which > >> contain the list of files (like the gpyi files already do today) isn't > a new > >> build system. It only offers the existing meta build systems (CMake, > GYP, > >> autotools, qmake) to use a common base. > >> > >> The remaining build systems can be ported to one of these systems or be > >> adopted to use this file lists too. > >> > >> -- Patrick > > > > I suspect that we would quickly find that we would want some sort of > > support for conditionals and/or file inclusion in our "simple text > > files", at which point you basically get a meta-meta-build system :). > > I don't actually think such a thing is that bad of an idea, but it's > > all in the details. > > > > I would like to find a solution where all of the ports were able to > > retain integration with their "native" build environments one way or > > another. > > > > -- Dirk > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
