Hi Jeremy,

On Aug 12, 2010, at 7:37 AM, Jeremy Orlow wrote:

> On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer <[email protected]> wrote:
> On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc <[email protected]> wrote:
> 
> > i completely agree with jeremy. is it possible to at least drop the cryptic 
> > hashcodes/timestamps? without them, the .xcodeproj files should at least be 
> > editable by hand.
> 
> Doesn't gyp already generate Xcode projects for Chrome?  I think the issue is 
> that gyp can't generate replacement project files for Apple's Mac port or 
> other build systems yet.  That was my take-away from the last 
> discussion--that gyp needed to be enhanced so that all build systems could be 
> generated, making addition or removal of source files a trivial task.
> 
> Chrome has been using GYP for some time and it's pretty stable.  I suspect 
> that anyone trying to port the Mac port's xcode project to it will run into 
> some bugs and/or need to build some additional features into it, but it is 
> quite stable.  And the GYP guys are very friendly people though, so I bet 
> they'd be happy to help with any such problems.  It's also worth noting that 
> GYP was designed from the start to allow a project to move over to it slowly 
> (you can have custom projects depend on GYP projects and vice versa).
> 
> But moving to GYP is definitely not the only way to solve this issue--and 
> quite possibly not the best way.  I suspect that there are also many smaller 
> steps that could be taken that'd have a big impact.  For example, coming up 
> with ways to generate sane/informative error messages for when someone 
> doesn't export some symbol/header file properly would awesome and doesn't 
> require changing the entire build system.  Or creating some script that can 
> add files to the xcode project.

One project I've been meaning to hack on once I take care of some higher 
priority work I'm doing is to update WebKitTools/Scripts/update-sources-list.py 
to pull sources from GYP instead of the code in there to pull sources from (now 
defunct) Bakefile build system. The idea here is that we can make changes to 
the source list in one place (say, the GYP files), then run this script and it 
will update the file lists for other ports that use text-based lists, like GTK, 
Qt and any ports using CMake. This I think would make updating a lot more 
straightforward and reduce the need for manually making the same change in 6 
different build systems. Adding XCode and MSVC support certainly would be 
possible too, but if ports using those files are still interested in doing a 
switch to GYP in the near future, it may not make much sense to bother with it.

I've also been working on https://bugs.webkit.org/show_bug.cgi?id=27551, which 
would allow us to stop using export symbol definition files and instead have 
the export info in the headers instead, so that all ports can use them rather 
than having each port define its own export symbols file. That's another thing 
that I think could reduce a lot of redundant maintenance.  

Regards,

Kevin

> J
> _______________________________________________
> webkit-dev mailing list
> [email protected]
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to