With OSX 10.7, the default method for installing XCode now sends you through the App Store. Installing XCode through the App Store does not install the Command Line tools by default, so this additional step needs to be added to this section of of webkit.org.
Created attachment 130417 [details] patch with update to XCode installation instructions
Created attachment 130432 [details] updated doc with specific XCode version
Comment on attachment 130432 [details] updated doc with specific XCode version View in context: https://bugs.webkit.org/attachment.cgi?id=130432&action=review I'd suggest rewording this to look something like: Install the Xcode Command Line Tools (Xcode 4.3 and newer) Xcode 4.3 and newer do not install the command line tools by default. You should install them from Xcode's Downloads preference pane. > Websites/webkit.org/building/tools.html:11 > +<li><p>Install the XCode Command Line Tools (located under XCode Preferences > Downloads) As you can see in the lines above, it's "Xcode" and not XCode.
Comment on attachment 130432 [details] updated doc with specific XCode version View in context: https://bugs.webkit.org/attachment.cgi?id=130432&action=review > Websites/webkit.org/building/tools.html:12 > +<li><p>Install the XCode Command Line Tools (located under XCode Preferences > Downloads) > + <p><b>Note:</b> In XCode versions earlier than 4.3, these are already installed by default, so this is not a required step. If installing XCode 4.3 for Lion or higher through the App Store, the command line tools are not be installed by default and this is required. It’s Xcode, not XCode. Also, the Note is too long! It should just say “This step is not required for versions of Xcode older than 4.3.”
Created attachment 130440 [details] changed XCode to Xcode & shortened the Note
(In reply to comment #0) > With OSX 10.7, the default method for installing XCode now sends you through the App Store. Installing XCode through the App Store does not install the Command Line tools by default, so this additional step needs to be added to this section of of webkit.org. It’s good to document this, but it would be even better to change the various WebKit tools that currently depend on the Command Line Tools component to not do so.
(In reply to comment #6) > (In reply to comment #0) > > With OSX 10.7, the default method for installing XCode now sends you through the App Store. Installing XCode through the App Store does not install the Command Line tools by default, so this additional step needs to be added to this section of of webkit.org. > > It’s good to document this, but it would be even better to change the various WebKit tools that currently depend on the Command Line Tools component to not do so. Thanks for the comment. What do you mean by that? Is it possible to build WebKit without the Xcode command line tools?
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #0) > > > With OSX 10.7, the default method for installing XCode now sends you through the App Store. Installing XCode through the App Store does not install the Command Line tools by default, so this additional step needs to be added to this section of of webkit.org. > > > > It’s good to document this, but it would be even better to change the various WebKit tools that currently depend on the Command Line Tools component to not do so. > > > Thanks for the comment. What do you mean by that? Is it possible to build WebKit without the Xcode command line tools? I believe you when you say that it is currently not possible to do so. Without knowing exactly what issues you run into I can’t tell for sure how they can be resolved, but I believe it would mostly involve using xcrun(1) to invoke certain tools where the scripts currently don’t, and perhaps running xcode-select(1) once.
(In reply to comment #8) > Without knowing exactly what issues you run into I can’t tell for sure how they can be resolved, but I believe it would mostly involve using xcrun(1) to invoke certain tools where the scripts currently don’t, and perhaps running xcode-select(1) once. Starting from a fresh install of OS X 10.7.3, after installing Xcode 4.3.1 from the Mac App Store and the Java for Mac OS X 10.7 Update 1 Developer Package from <http://connect.apple.com/>, I was able to syaty building WebKit with this command (the build hasn’t finished yet): Tools/Scripts/build-webkit --debug SDKROOT=/Applications/Xcode.appl/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk I did get a couple of errors about not being able to find ranlib, when build-webkit tried to copy WebKitSystemInterface to the built products directory. The script needs to be changes to invoke ranlib via xcrun.
s/syaty/start/
It occurs to me that installing the Java package was unnecessary, since it is included in the Mac OS X 10.7 SDK. It only served to bypass build-webkit’s check for its presence in /.
(In reply to comment #9) > (In reply to comment #8) > > > Without knowing exactly what issues you run into I can’t tell for sure how they can be resolved, but I believe it would mostly involve using xcrun(1) to invoke certain tools where the scripts currently don’t, and perhaps running xcode-select(1) once. > > Starting from a fresh install of OS X 10.7.3, after installing Xcode 4.3.1 from the Mac App Store and the Java for Mac OS X 10.7 Update 1 Developer Package from <http://connect.apple.com/>, I was able to syaty building WebKit with this command (the build hasn’t finished yet): > Tools/Scripts/build-webkit --debug SDKROOT=/Applications/Xcode.appl/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk > > I did get a couple of errors about not being able to find ranlib, when build-webkit tried to copy WebKitSystemInterface to the built products directory. The script needs to be changes to invoke ranlib via xcrun. Do you think modifying the script is a better way to go than updating webkit.org? If so, shouldn't that be a separate bug? As is is now with installing 4.3 or higher, there are definitely 2 additional steps: 1) installing the command line tools and 2) running xcode-select -switch to point to /Applications/Xcode.app/Contents/Developer . The build-webkit script does inform you of these two things, but it might be nice to have it documented up front as well.
Dan's point is that it shouldn't be necessary to install the command line tools package. If it's not necessary to install that package then there's no need to update the instructions. I'd suggest that we file a new bug about fixing things to not require the CLI tools, fix it, and then close this bug without doing anything.
(In reply to comment #13) > Dan's point is that it shouldn't be necessary to install the command line tools package. If it's not necessary to install that package then there's no need to update the instructions. That was my point. However, there is another issue with building without the Command Line Tools, which I don’t know immediately how to solve. > I'd suggest that we file a new bug about fixing things to not require the CLI tools, fix it, and then close this bug without doing anything. I filed bug 80915. In the meantime, I think it’s fine to change the instructions.
Comment on attachment 130440 [details] changed XCode to Xcode & shortened the Note View in context: https://bugs.webkit.org/attachment.cgi?id=130440&action=review > Websites/webkit.org/building/tools.html:11 > +<li><p>Install the Xcode Command Line Tools (located under Xcode Preferences > Downloads) <p><b>Note:</b> This step is not required for versions of Xcode older than 4.3. Please close the <p> tags.
Created attachment 131645 [details] closed <p> tag Fixed <p> tag per Dan's comment.
Created attachment 131646 [details] closed <p> tag Fixed <p> tag per Dan's comment.
Comment on attachment 131646 [details] closed <p> tag You closed one <p> but not the other. I will fix this when committing the patch.
Landed in <http://trac.webkit.org/r110579>.
Comment on attachment 131645 [details] closed <p> tag Cleared review? from attachment 131645 [details] so that this bug does not appear in http://webkit.org/pending-review. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).