In article <[email protected]>, Paul Bennett <[email protected]> wrote:
> On 30 Oct 2013, at 23:04, Ned Deily <[email protected]> wrote: > > In article <[email protected]>, > > Rainer Muller <[email protected]> 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, [email protected] _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
