On Wed, Dec 15, 2010 at 9:04 AM, Richard Wackerbarth <[email protected]> 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 _______________________________________________ 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
