[webkit-dev] Build system update

[Maciej Stachowiak]

On Mar 23, 2011, at 3:33 AM, Adam Barth wrote:

>>>> While this is certainly technically feasible, it would add a huge amount of overhead to the process of performing a submission.
>>> 
>>> How often do you submit WebKit to the Apple internal build system?  If
>>> that's sensitive information, I'm just looking for an order of
>>> magnitude (e.g., every revision, every hour, every day, every week).
>>> As a reference, the Chromium project creates one branch per day for
>>> daily builds.
>> 
>> I don't see how the frequency is relevant.
> 
> The relevancy arises from the observation that the overhead is
> proportional to the frequency.  If we only submit WebKit to Apple's
> internal build system once a week, then this approach won't cause too
> much branch proliferation.  If, on the other hand, we're submitting
> every revision, then we're talking about doubling or tripling the
> revision burn rate, which might not be desirable.
> 
>>> In any case, I'm glad we've found a technically feasible solution.
>> 
>> We've had at least one technically feasible solution from day zip: check in the generated project files.
> 
> From my perspective, approach (2) is more desirable than checking in
> generated project files because approach (2) encapsulates
> Apple-internal build process to Apple folks, more specifically to the
> Apple folks who interact with the Apple-internal build system.
> Checking in generated project files, on the other hand, imposes a
> maintenance burden on all WebKit contributors.

I believe Apple submissions generally happen with greater frequency than the rate at which new files are added to the project. Furthermore: When files are added to the project, the patch submitted must already run the tool to regenerate projects, and is already going to submit a patch, so the maintenance burden of the Xcode projects being checked in is low. But having to regenerate project files and then check them in on a branch adds extra steps, doing things that are not done in the normal course of development, and therefore may have bitrotted.

I don't think you are going to get Apple folks enthusiastic about switching to a build system that creates significantly more work for us, on the basis that it saves everyone else a small amount of work. For that matter, slowing down the pace of Apple engineers' development would be a bad thing for the project overall, not just for Apple.

Regards,
Maciej