[CMake] A comment on bug resolution

Wed Dec 15 09:34:11 EST 2010

On Wed, Dec 15, 2010 at 9:30 AM, David Cole <david.cole at kitware.com> wrote:
> 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
>

Having said all that, let me address your specific concern regarding
the issue closed:
I agree that the underlying reason for the request is a valid thing to
want, but the request expresses it poorly, and I do not understand
what exactly it is that the requester is looking for. An explicit
"please provide a way to determine the "best" target architecture on a
system" request (or whatever the real request is) would be better.

Asking us to change something that's already in use in the real world
(where changing it has real consequences for our existing user base)
especially where there are multiple interpretations of what that thing
means is not reasonable. (Again, in my opinion...)

Thanks,
David