xcodeversion portgroup: Don't fail if Xcode.app can't be found

[eturro@…]

In the age of expensive SSDs, many of us like to delete /Developer (10GB!) after having installed Xcode. AFAIK, MacPorts don't need anything in /Developer. Most ports issue a warning if /Developer has been removed: "Warning: Xcode does not appear to be installed; most ports will likely fail to build", after which the port proceeds to being successfully built. zlib, however, does its own manual check to see if Xcode.app exists and fails with an error "Error: Couldn't find Xcode; expected it to be at /Developer/Applications/Xcode.app". Could you please change the code so zlib behaves like other ports (i.e. issues a warning but doesn't quit with an error).

[ryandesign (Ryan Carsten Schmidt)]

Replying to eturro@…:

In the age of expensive SSDs, many of us like to delete /Developer (10GB!) after having installed Xcode. AFAIK, MacPorts don't need anything in /Developer.

I understand your motivation for wanting to free space on an expensive SSD, however I can't really support your way of going about it. /Developer/SDKs, for example, is essential to many ports.

Most ports issue a warning if /Developer has been removed: "Warning: Xcode does not appear to be installed; most ports will likely fail to build", after which the port proceeds to being successfully built.

Actually, that's MacPorts base​ checking for that and printing that message. It does so for all ports, if the problem exists.

zlib, however, does its own manual check to see if Xcode.app exists and fails with an error "Error: Couldn't find Xcode; expected it to be at /Developer/Applications/Xcode.app".

Actually, zlib is using the xcodeversion portgroup​ to perform this check. Many ports use this portgroup besides zlib, but since zlib is a dependency for so many other programs, it's often the first port that gets installed. That makes it a great place to check to make sure the user's Xcode is installed properly. The xcodeversion portgroup was added before MacPorts base had the similar check above, but I prefer the xcodeversion check precisely because it actually errors out and makes the user fix the problem. /Developer/Applications/Xcode.app is a standard part of Xcode; if you don't have that, how can I know that the rest of the developer tools are installed correctly?

Could you please change the code so zlib behaves like other ports (i.e. issues a warning but doesn't quit with an error).

The xcodeversion check was deliberately added to the zlib port because many users had upgraded Mac OS X but had not realized they needed to upgrade Xcode manually as well. This caused many problems across the board. There was a problem with zlib that I believe was traced back to this as well: zlib would appear to install without error, but in fact did not contain the zlib library, a rather important feature of the zlib port. Therefore I added the xcodeversion check to ensure that users with nonfunctional Xcode installations were prevented from creating this broken situation in the first place, thus saving time for both users (they don't have to ask us what's wrong) and us (we don't have to spend time answering questions about known situations).

Perhaps your need can be met another way. 9GB of the 11GB in my /Developer directory are taken up by the Platforms directory. All but 16MB of those 9GB relate to iOS development; if you're not doing iOS development, you could delete those directories and keep the rest.

Apple used to provide an Xcode installer that did not include the iOS development components, but they appear to have stopped doing so a few versions ago. Our Guide says you can ​download Xcode 3.2.2 without iOS, then use Software Update to update it to the latest version 3.2.6; I assume that means it won't pull in all the iOS parts in the process. So you could also uninstall Xcode using Apple's script, then install Xcode without iOS. (I'm not sure if there are parts other than those in /Platforms that would be omitted by doing this, which might give even greater space savings.) The Documentation and Examples directories are also relatively safe candidates for deletion, though they're not that large on my system.

[eturro@…]

I understand there are complications. My point is simply that checking the existence of /Developer/Applications/Xcode.app is an unreliable proxy for checking that the system meets all the requirements for building ports. This is likely to become more of a problem as SSDs become more prevalent and disk space more precious and people are forced to delete files they don't use. In my experience, literally everything in /Developer except for Xcode.app (whose existence some ports check) can be deleted and ports will continue to build fine. If anyone can think of a better proxy for checking that a system meets the requirements for building ports, this would be welcome.

[ryandesign (Ryan Carsten Schmidt)]

/Developer/SDKs is needed by many ports; don't delete it. The things in /Developer/usr might be needed as well by some ports; I'm not sure.

/Developer/Library contains the scripts that let you uninstall Xcode; if you remove them, you no longer have a clean way of removing all of Xcode later.

/Developer/Applications/Xcode.app is only 8MB; I don't think it's unreasonable to ask users to keep that around. You're right that the presence of Xcode.app doesn't guarantee all of developer tools is there and working properly, but short of checking every file installed by Xcode, and maintaining a list of every file every version of Xcode is supposed to install, I'm not sure there is an exhaustive solution.

In the xcodeversion portgroup, I chose to use the plist inside Xcode.app to determine the installed version of Xcode, because I could find no other way to do so. In MacPorts base, we instead used "xcodebuild -version". Earlier versions of xcodebuild don't show the Xcode version, so in those cases, we have a long list of known DevToolsCore versions​ and their corresponding Xcode versions. We could bring that list into the xcodeversion portgroup (or perhaps even just use the variable MacPorts base sets, if we can get access to it) if we really want to allow users to remove Xcode.app.

Note that "disk space is cheap" is a mantra that we have adopted pervasively in MacPorts. For example, ports are generally engineered to have as many features as possible, even if that means pulling in a few dependencies you personally might not need, or installing some documentation you personally might never read. It's worth it to us, for the sake of the users for whom those items are important, and it makes it possible for other ports to declare dependencies on them and know that the features will be there.

[eturro@…]

May I suggest an entry is added to the MacPorts wiki specifying which Xcode files are actually needed by MacPorts? As the "disk space is cheap" mantra is valid for HDDs but not for SSDs, and since Xcode now comes with a lot of iOS stuff which many users might not need, an entry explaining how they can "trim down" their Xcode install without deleterious consequences would be very welcome, wouldn't you agree?

[jmroot (Joshua Root)]

r78033

Deleting /Developer is still unsupported, done at your own risk, and generally a terrible idea. Might I suggest installing the Xcode package without the iOS SDK? (Note you'll need to run Software Update afterwards.) ​https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20588

[eturro@…]

I just realised it is in fact possible to install Xcode 3.2.6 directly without the iOS SDK. Although the "Essentials" component is greyed out in such a way that it looks like there is no choice but to install all of it, there is a sub-menu that can be displayed by clicking on the the grey triangle, which allows the user to untick iOS SDK (saving 8.26GB). Someone should update the MacPorts guide, as it is not necessary to download 3.2.2 and then update to avoid installing the iOS SDK.

[ryandesign (Ryan Carsten Schmidt)]

Replying to eturro@…:

I just realised it is in fact possible to install Xcode 3.2.6 directly without the iOS SDK.

Thanks for finding this and pointing it out. This is helpful if you've already downloaded Xcode 3.2.6 with iOS and don't want the iOS parts. But it is still an unnecessary use of bandwidth and time to download Xcode 3.2.6 with iOS if you're not going to install the iOS parts, so if you haven't downloaded yet, you may still be better off downloading Xcode 3.2.2 without iOS and then updating it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to eturro@…:

May I suggest an entry is added to the MacPorts wiki specifying which Xcode files are actually needed by MacPorts? As the "disk space is cheap" mantra is valid for HDDs but not for SSDs, and since Xcode now comes with a lot of iOS stuff which many users might not need, an entry explaining how they can "trim down" their Xcode install without deleterious consequences would be very welcome, wouldn't you agree?

What I meant to say was that because we have for years now subscribed to the idea that disk space is cheap (notwithstanding the fact that this does not apply to SSDs), consequences of this can be seen throughout MacPorts. The large Xcode install is not going to be the only place where you might experience greater disk usage than you, with an expensive disk, are comfortable with. I'm explaining that this is not easy to change in MacPorts at this time.

I agree a document in the wiki about how to reclaim some disk space would be welcomed. Possible subtopics could include removing parts of Xcode that aren't needed, removing distfiles, uninstalling inactive ports, uninstalling leaves, cleaning failed partial builds, .... I don't have time to write this document now, but anyone else should feel free to do so; the wiki is open for anyone with a Trac account to edit.