On Wed, Mar 23, 2011 at 11:38 AM, Mark Rowe <[email protected]> wrote: > On 2011-03-23, at 03:33, Adam Barth wrote: >> On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe <[email protected]> wrote: >>> On 2011-03-22, at 23:50, Adam Barth wrote: >>>> On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe <[email protected]> wrote: >>>>> Product names for targets are redundantly declared in the Xcode project >>>>> when they're already defined in the .xcconfig files. >>>> >>>> My plan for this issue is to remove the product names from the >>>> xcconfig files once they're not needed by the generated xcodeproj >>>> files. >>> >>> That seems backwards. JavaScriptCore.xcconfig defines how to create >>> JavaScriptCore.framework. The name of the framework (e.g., PRODUCT_NAME) >>> is an important part of that, much like the install path, Info.plist file, >>> etc. I don't see how we benefit from that information being spread around. >> >> The information about how to create JavaScriptCore.framework is >> already spread around to a certain extent. For example, >> JavaScriptCore.xcconfig does not contain the list of files that need >> to be built or information about the dependencies. I'm having a hard >> time seeing what the practical difference is between specifying the >> product name in the xcodeproj file or the xcconfig file. > > What's the argument for changing where it is specified? Is it simply because > gyp doesn't know better?
Yes. Also, the names of the other targets are stored in the xcodeproj files. I don't see this as a blocking issue, do you? >>>>>> One area that I could use some help from one or more Apple folks is >>>>>> making sure that this build system integrates properly with Apple's >>>>>> internal build system. Based on my (incomplete!) understanding of >>>>>> Apple's internal build system, there are at least two options: >>>>>> >>>>>> 1) Apple's internal build system consumes Source in its entirety and >>>>>> builds a master WebKit.xcodeproj (or a Makefile), which abstracts >>>>>> further details about the build, such as how subsequent xcodeproj are >>>>>> created or how many libraries WebKit is factored into (e.g., letting >>>>>> us extract WTF from JavaScriptCore). >>>>> >>>>> Making that particular change is completely unrelated to GYP. >>>> >>>> My understanding is that it would solve the Apple internal build >>>> system integration issue because the Apple internal build system would >>>> transfer control to the master WebKit.xcodeproj, which could then >>>> invoke GYP to generate the remaining xcodeproj files. >>> >>> I'm not particularly keen on a solution that involves manually invoking >>> xcodebuild to build projects. It becomes very complicated to ensure that >>> the correct settings, including any overridden settings, make it down to >>> the nested invocations of xcodebuild. >> >> I'm not sure I've correctly communicated how I envision this approach >> working. If approach (2) doesn't work out for whatever reason, I can >> build a mockup of how this would work, which will be more concrete. > > You'll need to provide more detail then because I cannot see how this would > work in a manner that doesn't cause the problems I have noted. As I wrote above, we can discuss this more at a later date, if necessary. >>>>>> 2) For each submission to Apple's internal build system, we create a >>>>>> branch, generate xcodeproj files, and check them into the branch. >>>>>> Apple's internal build system can then "svn export" the branch and see >>>>>> xcodeproj files, as today. >>>>> >>>>> 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. > > The rate at which we use SVN revisions or the number of branches isn't of > particular concern to me. The simple fact is that your proposal turns a > single, trivial operation (create a tag) in to a sequence of more complicated > operations (create a branch, check it out, run a script to generate a bunch > of files, test that it builds, commit the new files, create a tag). What > used to be a single command-line operation that took a second to run is now a > series of operations that takes 5+ minutes to complete. 5 minutes doesn't sound like much of a burden given that it's paid only by one person (as opposed to every contributor) can easily be automated. >>>> 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. > > The maintenance burden you mention is minuscule in comparison to the existing > requirement of updating umpteen different build systems, including the > impossible-to-hand-edit Xcode project files. This is particularly true when > we're still going to be updating umpteen minus one build systems for the > foreseeable future. If the Xcode project files were the only remaining > project files then I'd certainly take this argument more seriously. Yes, unifying all our various build systems is a long journey and this is just the first step. > One issue that's been touched on but not stated explicitly is what the > workflow will be for the average developer that wants to build WebKit. > Currently to update and build I do something like the following: > git svn rebase (or svn up) > make debug > > Presumably people that use this workflow would need to add an extra step > between those two commands to generate project files? That would flow should work fine. There's no need to alter it. On Wed, Mar 23, 2011 at 11:56 AM, David Levin <[email protected]> wrote: > On Wed, Mar 23, 2011 at 3:33 AM, Adam Barth <[email protected]> wrote: >> On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe <[email protected]> wrote: >> >> 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. > > Living with the chromium system of generating the files on the fly, I always > find it bothersome when the slowest step (by far) of my sync is generating > these project files. > So I personally prefer checking in the generated files (and letting this > delay be on the person making the change -- rather than distributing this > generation step to everyone). (As Mark mentions) this seems to also have the > benefit of disrupting people's workflow the least. $ time git svn rebase [... update my working copy from changes during lunch (four revisions) ...] real 1m10.316s user 0m8.194s sys 0m16.400s $ time ./Tools/Scripts/generate-project-files real 0m4.339s user 0m3.888s sys 0m0.269s which is about 6.1% overhead on an almost trivial update. We can also reduce this overhead to zero in many cases by detecting that we don't need to re-generate the project files if the inputs to the generation process haven't changed. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
