[CMake] Xcode without 'command line tools' & xcrun & CMake

[Bill Hoffman]

On 7/17/2012 2:41 PM, Sean McBride wrote:
> On Tue, 17 Jul 2012 14:22:20 -0400, Bill Hoffman said:
>
>>> Not that I know of.  That would be analogous to...?  What would it do?
>>
>> In VS it setups the environment to run CC from the command line.
>>
>>>
>>> For now, I've created this bug:
>>>
>>> CMake should support default installation of Xcode.app only, without
>> 'command line tools' extras
>>> <http://public.kitware.com/Bug/view.php?id=13408>
>>>
>> I am not sure I agree with the statement.  CMake has always required
>> that the command line tools that it uses be in the environment.  I
>> really don't see how CMake could technically use xcrun to configure an
>> environment correctly so that things would work.  On all platforms CMake
>> requires the environment to work from the command line.
>
> Well, I don't know enough about how cmake works internally, but I was under the impression that it looks for things in certain well-known places in hopes of finding them.  I just greped the code for 'usr/local/bin' and here's an example of what I mean:
>
>    set(gp_cmd_paths ${gp_cmd_paths}
>      "C:/Program Files/Microsoft Visual Studio 9.0/VC/bin"
>      "C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin"
>      "C:/Program Files/Microsoft Visual Studio 8/VC/BIN"
>      "C:/Program Files (x86)/Microsoft Visual Studio 8/VC/BIN"
>      "C:/Program Files/Microsoft Visual Studio .NET 2003/VC7/BIN"
>      "C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/VC7/BIN"
>      "/usr/local/bin"
>      "/usr/bin"
>      )

That is to find ONE executable, devenv.  We do that to find Xcode. 
However, to find an entire tool chain for a compiler is a whole 
different story.

>
> Is this not a trial-and-error way of finding which folder holds the
> sought item?  Wouldn't it be a matter of extending this facility?
> (Not that I'm saying it would be trivial to do so...)
>>> Perhaps these tests should only be run conditional on the presence
>>> of
>> PackageMaker instead of allowed to fail hard?
>>>
>> This we might be able to fix.
>
> Cool.  Shall I create a bug for that?
>
Sure.

-Bill