[CMake] A comment on bug resolution

[Richard Wackerbarth]

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.)

Richard