Maverics/Xcode 5 proposal: no more xcode-select --install

[Ned Deily]

In article <CC254915-35CD-43A3-9F4F-47D4D8F70A1F at angellane.org>,
 Paul Bennett <t21 at angellane.org> wrote:

> On 30 Oct 2013, at 23:04, Ned Deily <nad at acm.org> wrote:
> > In article <52711F90.70809 at macports.org>,
> > Rainer Muller <raimue at macports.org> wrote:
> >> Well, after thinking about this again, we could also do it the other way
> >> around. The majority of ports already builds just fine if you have the
> >> Command Line Tools only, without Xcode (ignore warnings from base about
> >> missing xcodebuild, it's not actually required in this case).
> [...]
> > From the outside looking in, that strikes me as a much more realistic and 
> > potentially achievable goal.
> 
> I'd still like to encourage considering both cases:
> 1. When Xcode is installed, but Command Line Tools aren't
> 2. When Command Line Tools are installed, but Xcode isn't
> 
> From my position, I don't see that the scale of 2 is significantly different 
> to 1, particularly since in both cases the shims - including xcrun - will be 
> there to assist locating the relevant tools, headers and libraries.

The problem I see with proposal one is that there are plenty of upstream 
projects that make assumptions about file locations, like header file 
locations, and were never designed to take into account the use of an an SDK.  
The Apple compiler drivers handle the cases involving compiler and linker 
calls, e.g. through the use of -isdkroot and the under-the-covers appending 
the SDK prefix to paths to "system" locations, but that doesn't and can't help 
with paths that are embedded or, worse, computed dynamically elsewhere in a 
project's build steps.  For example, python builds use a python script for the 
steps of building the C extension modules in its standard library.  At build 
time, the script does a lot of searching around to find include files and 
library files to determine which extensions to build and/or how to build them.  
To support SDK builds, we (the Python project) had to go in and modify 
setup.py to do the SDK path modifications itself and sometimes we slip up.  In 
the best case, that produces a build error; in other cases, it hasn't but 
created a component with subtle bugs.  I'm sure there are plenty of other 
cases in other projects.  The problem is that it's impossible to identify all 
of these uses automatically.  And even if you catch some of them and send the 
changes back upstream (and if you don't, you've just added an on-going 
maintenance headache), there still is no guarantee that you've caught most of 
them.

Proposal two is much easier because that's how projects are built on most 
other Unix-y platforms.  Only OS X specific ones and ones where, for some 
reason, the upstream project came up with an xcode project file would you 
really need to have Xcode.app installed.

-- 
 Ned Deily,
 nad at acm.org