On Feb 20, 2012, at 3:15 AM, Dan Ports wrote: > On Fri, Feb 17, 2012 at 10:32:48AM -0800, James Berry wrote: >>> (2) If developer_dir is not set, or is not correct, do the following, >>> in order >>> >>> (a) Use any valid value from: xcode-select -print-path (the >>> user has chosen an Xcode, or Xcode's default is correct) > > [...] > >> I've basically implemented 2.a and 2.b in r88970-88971, btw. The only caveat >> being that if the user has explicitly set an invalid developer_dir in >> macports.conf, I don't catch or warn about that. > > I tried this on a fresh Lion install that didn't have a previous > installation of Xcode. I installed 4.3 and didn't run xcode-select, > leaving it with no selected Xcode. I didn't get any warnings about > needing to run xcode-select. > > I'll take a closer look tomorrow, but I think what's going on here is > that xcode-select exists, but fails to run. `xcode-select -print-path` > gives an error message and returns with a non-zero error code, and > set_developer_dir doesn't handle that.
Dan: thanks. Any more information you can give about the failure mode would be appreciated. According to my testing, xcode-select -print-path can be safely run even if you've never agreed to the Xcode agreement, so I don't think that's what this is, though I could be wrong. Is it truly the case that xcode-select -print-path did return an error code, or didn't return a valid path? If the path it was returning was valid, maybe everything was working just right. A last alternative is that mdfind wasn't finding any Xcode's, a case in which we give the user no pre-fabricated command lines, and also no warning at all (something can happen, as you know, if the spotlight index isn't complete yet) James _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
