On Apr 22, 2013, at 21:23, Ned Deily wrote:

> That's correct.  xcode-select sets the defaults that are used by several 
> other build tools, primarily xcodebuild and xcrun but it has no effect 
> on what is installed in system locations.  If you allowed the Xcode 4.2

Yes. xcode-select is just a very basic script that updates a file, from which 
in turn other scripts read the prefix to prepend to /usr/bin (etc) when 
invoking the necessary commands. Just an extra indirection.

> Installer to install the command tools package (I'm not sure what the 
> package name is for Xcode 4.2), you would need to re-install the 3.2.6 
> UNIX Development package using the Xcode 3.2.6 Installer to get the 
> proper executables and header files installed in /usr/bin, /usr/include, 
> /System/Frameworks, et al.  First, though, you should uninstall the 4.2 
> command tools by using the uninstaller script from the Xcode 4.2 
> /Developer directory:

I think this applies only if you installed 4.2 to its default location. I 
haven't had to do any of this - my Unix toolchain still uses the 3.2.6 
executables if I refer to the default tools, but Xcode 4.2 uses its own 
versions from within its IDE. Exactly as I had hoped.

I must admit I hadn't thought about universal build implications of choosing a 
non-Apple compiler. Curiously, the first port of which I installed a universal 
variant was ffmpeg, and that package cannot (easily) be built as universal by 
simply specifying the desired architectures. I've presumed that Macports 
followed the same approach as Xcode, i.e. build each architecture in parallel 
and then pull in (lipo) the resulting binaries. More cumbersome, but if the 
build engine allows to do this it does have advantages (finer control over 
compiler options). And of course it works with any compiler that supports the 
desired architectures!

Out of curiosity: is gcc-4.2 the last compiler for which Apple made it possible 
to build it on systems where you cannot obtain the binaries directly from 
Apple? If so, are there any plans to provide ports of those compilers 
(supposing there's any interest to that ... introducing features like ARC which 
aren't supported by the runtime isn't particularly useful ...)

I updated https://trac.macports.org/wiki/XcodeVersionInfo as requested.

R.
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to