[webkit-dev] Build system complexity

[Jeremy Orlow]

Let me re-iterate (because even some co-workers are getting confused): I'm
not secretly trying to get the mac port to start using GYP.  (Or saying it's
a bad idea either, mind you.)  I'm just concerned that the process
associated with adding a file (or adding a dependency between projects on
the mac port) is out of hand--and has been for some time.  And I'm hoping we
can come to some sort of conclusion that'll start the project moving in the
right direction--even if it's slowly.  That's it.  I promise!

J

On Thu, Aug 12, 2010 at 3:37 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer <ddkilzer at webkit.org> wrote:
>
>> On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc <dumi at chromium.org> 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.
>
> J
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100812/e135f71e/attachment.html>