The parser (and the grammar) works the way it does because it’s just Python—the whole thing can be slurped in quickly by the interpreter and made available to GYP as data. It’s faster than a parser written in Python for a similar language would be, and it’d likely take a binary Python module to approach or exceed this speed. Developers don’t like waiting for tools.
With that in mind, I’d be open to experimenting with alternative (probably optional) formats. On Tue, Feb 5, 2013 at 7:48 AM, Simon Hausmann <[email protected]>wrote: > On Monday, February 04, 2013 10:57:46 AM Maciej Stachowiak wrote: > > On Feb 4, 2013, at 10:46 AM, Mark Mentovai <[email protected]> wrote: > > > GYP was written in Python to address point (b). Python was already > part of > > > the baseline requirements on all platforms, so we already had Python > > > available everywhere we needed it. There are no dependencies on > external > > > binaries, and no compiled code needs to be checked in anywhere or > > > maintained as part of a base image. > > > > > > As for point (a), you can easily have a top-level Makefile not > generated > > > by GYP that says “run GYP to produce the build files for whatever > > > environment you like and then pass control to that build system to do > the > > > rest of the build. Developers who like it can use ninja for their own > > > builds, and your bots can use Xcode or make if that’s a requirement (or > > > if ninja doesn’t meet your requirements given point (b)). > > Checking in the generated Xcode projects is another alternative. The > > Makefile might be better for the reasons you suggest, though. > > > > I'm reasonably confident at this point that Gyp can meet our hard > > requirements. Our remaining issues are finding time to do it and > > comprehensibility/readability of the syntax. > > On the topic of the Gyp syntax: > > I find it pretty readable, but I wonder if you guys are open to the idea of > relaxing the parser a bit to also allow for the omission of quotes and > commas > for the dictionary keys. I feel a syntax like > > { > includes: [ > ... > ] > > variables: [ > ] > } > > is slightly less error prone to type and you could probably still support > the > "stricter" language, too. > > > Simon >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
