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

[Mark Anderson]

Will xcode-select --install work right without XCode.app? I do OSX and Mac
Dev, so I always have it, but I'm curious to try now.

—Mark
_______________________
Mark E. Anderson <emer at emer.net>


On Wed, Oct 30, 2013 at 7:52 PM, Ned Deily <nad at acm.org> wrote:

> 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
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20131030/ce788845/attachment.html>