[CMake] A comment on bug resolution

[David Cole]

On Wed, Dec 15, 2010 at 9:04 AM, Richard Wackerbarth <richard at nfsnet.org> wrote:
> 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
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>

In my opinion, "defining this away" is the only reasonable course of
action, because CMAKE_SYSTEM_PROCESSOR is an ambiguous concept.

CMAKE_SYSTEM_PROCESSOR, is it:
- the architecture of the processor on which cmake is currently running?
- the active architecture of a universal binary build of cmake (run
via "arch" on a Mac)?
- the default architecture for which executables will be built via
add_executable?
- the "most capable" architecture of the system, even if it's a 32-bit
app running on a 64-bit capable machine?

However, my only objective with the bug assignment/cleaning frenzy
I've been on in the last 24 hours is to get a grip on the out of
control CMake bug tracker.

If I resolve something incorrectly, and you disagree with it, please
re-raise the issue, either by re-opening an existing bug, creating a
new one again, or discussing here on the mailing lists.

My philosophy is that CMake should absolutely and unequivocally be the
fastest/strongest/best-all-around build-system-generator on the
planet, and doing what it takes to eliminate the chatter and noise in
the bug databse is part of making that happen. I welcome people with
dissenting opinions always, because they're more fun to talk to than
people who always agree with me... So keep it comin'!


Thanks for voicing your concern,
David