[CMake] A comment on bug resolution

[Rolf Eike Beer]

> The following is excerpted from a message that I received this morning.
>
> I think that it indicates a direction in the CMake philosophy which
> concerns me.
> (See below)
>
> On Dec 15, 2010, at 6:34 AM, Mantis Bug Tracker wrote:
>> The following issue has been RESOLVED.
>> ======================================================================
>> http://public.kitware.com/Bug/view.php?id=10326
>> ======================================================================
>> Reported By:                Luis Kornblueh
>> Assigned To:                David Cole
>> ======================================================================
>> Project:                    CMake
>> Issue ID:                   10326
>> ======================================================================
>> Date Submitted:             2010-02-23 11:09 EST
>> Last Modified:              2010-12-15 07:34 EST
>> ======================================================================
>> Summary:                    Wrong architecture for
>> CMAKE_SYSTEM_PROCESSOR
>> Description:
>> CMAKE_SYSTEM_PROCESSOR returns always i386 on MacOSX 10.6.x. But running
>> on a
>> MacPro I expect x86_64.
>
>> It seems uname -p is returned, but uname -m would be nicer ...
>> ======================================================================
>
>> ----------------------------------------------------------------------
>> (0024137) David Cole (manager) - 2010-12-15 07:34
>> http://public.kitware.com/Bug/view.php?id=10326#c24137
>> ----------------------------------------------------------------------
>> The documentation for CMAKE_SYSTEM_PROCESSOR clearly states that uname
>> -p is
>> used to determine its value:
>>
>> http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_SYSTEM_PROCESSOR
>>
>> In these days of universal binaries and cross-compiling, it is not meant
>> to be
>> used for anything other than a "best guess" about what your targets'
>> primary
>> architecture is going to be...
>>
>> If you must have some other value, then use some other means to get it.
>> CMAKE_SYSTEM_PROCESSOR is set to the output of "uname -p"
>
> IMHO, "defining away" an issue does not address the underlying reason for
> the request.
>
> If there were a readily available alternative, it is fine to point out
> that the user should have used that, already available, construct.
> However, CMake (or any other tool) is useful only to the extent that it
> allows someone to get their expected results with minimal "work-around"
> effort.
>
> Just as we have minimum and maximum OS deployment targets within an OS
> family, there are minimum and maximum cpu architecture features within the
> hardware lines.
>
> I believe that the "Wrong architecture for CMAKE_SYSTEM_PROCESSOR" bug
> filing was a result of a reasonable expectation that the "default"
> architecture would be readily available in the CMAKE_ namespace.
>
> As CMake evolves to handle the emulation of increasingly complex build
> environments, I fear that it is losing a lot of its value because the
> simplest case "project(simple); add_executable( SAMPLE main.c)" no longer
> is able "to do the right thing".
>
> If a tool does not allow me to do simple things easily, I am disinclined
> to use it for the moderately complex projects where it should be most
> useful. (The really complex projects always will remain "difficult"
> despite any tool set developed.)

I can understand that (even more as this was my report). But I also see
the compatibility problem. So it is ok for me that this bug is closed, but
there needs to be a new variable that get's this values (both for host and
target IMHO). And those must be properly defined, an issue that is shared
with the reporting of processor count by the SystemInformation class at
another place.

Eike