[CMake] What's happening to CMake ??? Please help !!!
Hello CMake users developers,
I've been trying to build ITK on my machine, and obviously is not related to
what is built, and CMake produces
some errors at the configuration step. Perhaps someoneelse has already
encountered
similar type of problem ?
My setup:
Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.7, Visual Studio .NET 2005
w/ Visual C++ 8
At first I've observed the following CMake Errror message box and then a lot
of errors coming up when I choose OK.
CMake Error: Unable to find executable for TRY_RUN: tried
Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe and
Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe and
Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe.
[CMake is correct; these files do not exist, but the log indicates no error
for the building of these executables.]
In order to debug the error I've created an empty foo.c like the following
#include stdio.h
void main(void)
{
}
and a CMakeLists.txt
add_library(foo foo.c).
I put them into the C:\CMakeTest folder.
I've changed my directory to the bin directory of CMake and run the
following command from the command console
cmake C:\CMakeTest\CMakeLists.txt --debug-trycompile
It produced the following output lines
debug trycompile on
--Check for working C compiler: cl
--Check for working C compiler: cl --works
--Check size of void* CMake Error: Unable to find executable for TRY_RUN:
tried C:/CMakeTest/CMakeFiles/CMakeTmp/cmTryCompileExec.exe and
C:/CMakeTest/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe and
C:/CMakeTest/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe.
--Check size of void* -done
--Check for working CXX compiler: cl
--Check for working CXX compiler: cl --works --Configuring done
I've check the availability of executables
1. C:/CMakeTest/CMakeFiles/CMakeTmp/cmTryCompileExec.exe is not available
2. C:/CMakeTest/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe is
available
3. C:/CMakeTest/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe is
not available and the folder Development does not exist.
and the solution CMAKE_TRY_COMPILE.sln in the folder
C:\CMakeTest\CMakeFiles\CMakeTmp is available and it can be built without
any errors.
I don't understand Although cmTryCompileExec.exe is available inside the
folder C:/CMakeTest/CMakeFiles/CMakeTmp/Debug CMake still produces CMake
error.
I've compiled previous version of ITK, or VTK, etc. without any problem
before, but after deleting old one and trying to build the latest release,
I've got these errors. I'd be grateful to anyone who help me resolve this
problem ?
Sincerely
Cem DEMiRKIR
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What's happening to CMake ??? Please help !!!
Cem DEMiRKIR wrote:
Hello CMake users developers,
I've been trying to build ITK on my machine, and obviously is not
related to what is built, and CMake produces
some errors at the configuration step. Perhaps someoneelse
has already encountered
similar type of problem ?
My setup:
Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.7, Visual Studio .NET 2005
w/ Visual C++ 8
At first I've observed the following CMake Errror message box and then a
lot of errors coming up when I choose OK.
CMake Error: Unable to find executable for TRY_RUN: tried
Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe and
Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe and
Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe.
[CMake is correct; these files do not exist, but the log indicates no
error for the building of these executables.]
In order to debug the error I've created an empty foo.c like the following
#include stdio.h
void main(void)
{
}
and a CMakeLists.txt
add_library(foo foo.c).
I put them into the C:\CMakeTest folder.
I've changed my directory to the bin directory of CMake and run the
following command from the command console
cmake C:\CMakeTest\CMakeLists.txt --debug-trycompile
It produced the following output lines
debug trycompile on
--Check for working C compiler: cl
--Check for working C compiler: cl --works
--Check size of void* CMake Error: Unable to find executable for
TRY_RUN: tried C:/CMakeTest/CMakeFiles/CMakeTmp/cmTryCompileExec.exe
and C:/CMakeTest/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe and
C:/CMakeTest/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe.
--Check size of void* -done
--Check for working CXX compiler: cl
--Check for working CXX compiler: cl --works --Configuring done
I've check the availability of executables
1. C:/CMakeTest/CMakeFiles/CMakeTmp/cmTryCompileExec.exe is not available
2. C:/CMakeTest/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe is
available
3. C:/CMakeTest/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe
is not available and the folder Development does not exist.
and the solution CMAKE_TRY_COMPILE.sln in the folder
C:\CMakeTest\CMakeFiles\CMakeTmp is available and it can be built
without any errors.
I don't understand Although cmTryCompileExec.exe is available inside the
folder C:/CMakeTest/CMakeFiles/CMakeTmp/Debug CMake still produces
CMake error.
I've compiled previous version of ITK, or VTK, etc. without any problem
before, but after deleting old one and trying to build the latest
release, I've got these errors. I'd be grateful to anyone who help me
resolve this problem ?
I can help, but you are going to have to do some work... :)
You are going to need to debug CMake with a debugger or with print
statements but you need cmake to build cmake. Maybe you can build with
the nmake generator on this machine. Try the simple test case with the
nmake makefiles generator. You will need to run cmake from the visual
studio command line tools prompt. If that works, then get the source
for cmake and build it with debug on. Then we can try and figure out
why cmake can not tell that file exists.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] too many kinds of FALSE
On 12/16/07, Brandon Van Every [EMAIL PROTECTED] wrote:
What's so great about n and no ?
Nobody has claimed that they are great...
I've never used them. Do we
really need to be polluting the interpretation of strings with these
values? What current or legacy code is using them heavily?
We cannot know. We can only assume that somebody somewhere is probably using
them since they are part of how CMake currently works.
If you have a suggestion on how to improve things without breaking backwards
compatibility, I'm sure we'd all love to hear it. But otherwise, I would
strongly suggest using STREQUAL instead of IF(VARIABLE) with any regex
result.
Instead of...
IF(thematch)
...you should use
IF(NOT ${thematch} STREQUAL 0)
I know it's not as pretty or elegant as the former, but it works always
regardless of the contents of thematch. In this particular case, it looks
like you are trying to test for 0 or non-0 as the last character of the
input and are mad that n is the same as 0 in a cmake variable-based IF
statement. Is that correct?
HTH,
David
ON and OFF are used in the Options, but why can't these just be TRUE
and FALSE, so that there's less variety of how we specify TRUE and
FALSE? Alternately, how about defining a boolean storage type to hold
options?
How about a numerical storage type, so that 0 and 0 aren't the same
thing? And so that we don't have to type MATH(EXPR var ${var} - 1),
we could just type var = var - 1. The problem with assuming that 0
means FALSE, is it assumes I got my 0 by counting with a MATH
expression. What if I got my 0 by matching with a regex, like a
digit of a library version?
-NOTFOUND doesn't trouble me so much, as it's unlikely to be
accidentally matched in a regex.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
Brandon Van Every wrote: On Dec 15, 2007 1:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote: I've subscribed to the SCons mailing list. The SCons community has people who got fed up with it and started their own RD. It seems that the SCons Python 1.5 limitation is a serious one, as developers generally only know Python = 2.2. Waf is the offering of a fellow who clearly thinks OO is important in a build system for some reason. http://code.google.com/p/waf/ A quick eval of waf * Its dependency checker is broken. /usr/include is not checked for speed. * Swig support is broken. * no real multi platform support, it is all do it yourself. * out-of-source builds is kind of broken. * proper out-of-source builds needs the wscript to be set up with variants (good idea, but badly done). * build dir creates stubs for all subdirectories, not only those in build (yuck). * no listing of tasks (yuck). * you are always forced to write a configure function (yuck). * WAY too verbose (yuck). * badly documented. In summary, thanks. But, no thanks. With all those problems I did not even bother checking the speed. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] too many kinds of FALSE
On Dec 16, 2007 11:57 AM, David Cole [EMAIL PROTECTED] wrote:
On 12/16/07, Brandon Van Every [EMAIL PROTECTED] wrote:
What's so great about n and no ?
Nobody has claimed that they are great...
I've never used them. Do we
really need to be polluting the interpretation of strings with these
values? What current or legacy code is using them heavily?
We cannot know. We can only assume that somebody somewhere is probably using
them since they are part of how CMake currently works.
What's an example in the CMake source pool where they're actually used
for something? Or VTK or ITK? I've never had a reason to use n or
N. Is this something from the earliest days of CMake that looked
like a good idea at the time, but that nobody really used?
If you have a suggestion on how to improve things without breaking backwards
compatibility, I'm sure we'd all love to hear it.
Sure. A function to turn off the interpretation of various kinds of
FALSE. That's generally how you'd handle any kind of backwards
compatibility problem. Give the user the ability to turn off legacy
behavior.
At the same time, one could provide type safe constructs, like boolean
variables, so that current CMake users adopt better practices. Over
time, you'll have a quorum of people turning off the legacy stuff.
Then perhaps the legacy behavior can be retired.
Another way to prod people into retiring legacy constructs, is to
issue warnings during execution about the existence of those
constructs. Or if that's too draconian, provide an option to issue
such warnings.
But otherwise, I would
strongly suggest using STREQUAL instead of IF(VARIABLE) with any regex
result.
...you should use
IF(NOT ${thematch} STREQUAL 0)
I know it's not as pretty or elegant as the former, but it works always
regardless of the contents of thematch.
I think you mean to recommend
IF(thematch STREQUAL )
I may do that from now on. But there's a gotcha waiting with that
style of coding: a null variable, and a variable set to an empty
string, are not equivalent.
SET(void)
SET(empty )
IF(void STREQUAL empty)
MESSAGE(void and empty are equivalent)
ELSE(void STREQUAL empty)
MESSAGE(void and empty are different)
ENDIF(void STREQUAL empty)
set(myvar)
if(myvar STREQUAL )
message(It would be prudent to initialize myvar, or Bad Things will happen.)
else(myvar STREQUAL )
message(Gosh I'm sure glad I initialized myvar, nothing bad will happen!)
endif(myvar STREQUAL )
C:\devel\src\cbugs\strequalcmake -P strequal.cmake
void and empty are different
Gosh I'm sure glad I initialized myvar, nothing bad will happen!
I think it cost me 1/2 a workday to figure that one out. Having to
remember these subtleties is really bad. Especially since they're not
documented; you can really only learn them through the school of hard
knocks. I think CMake needs a type safety injection somewhere.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] too many kinds of FALSE
On Sunday 16 December 2007, Brandon Van Every wrote:
On Dec 16, 2007 11:57 AM, David Cole [EMAIL PROTECTED] wrote:
On 12/16/07, Brandon Van Every [EMAIL PROTECTED] wrote:
What's so great about n and no ?
Nobody has claimed that they are great...
I've never used them. Do we
really need to be polluting the interpretation of strings with these
values? What current or legacy code is using them heavily?
We cannot know. We can only assume that somebody somewhere is probably
using them since they are part of how CMake currently works.
What's an example in the CMake source pool where they're actually used
for something? Or VTK or ITK? I've never had a reason to use n or
N.
n alone indeed also evaluates to false. Hmm, this really seems like a not so
good idea.
...
set(myvar)
if(myvar STREQUAL )
message(It would be prudent to initialize myvar, or Bad Things will
happen.) else(myvar STREQUAL )
message(Gosh I'm sure glad I initialized myvar, nothing bad will
happen!) endif(myvar STREQUAL )
C:\devel\src\cbugs\strequalcmake -P strequal.cmake
void and empty are different
Gosh I'm sure glad I initialized myvar, nothing bad will happen!
Try the following, this will make it always two strings:
if(${myvar} STREQUAL )
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
On Dec 16, 2007 1:11 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Waf is the offering of a fellow who clearly thinks OO is important in a build system for some reason. http://code.google.com/p/waf/ A quick eval of waf Ok, waf sucks. It can't demonstrate anything compelling about OO build systems in practice. But does it say anything about OO build systems in theory? Does the author have a good idea? Meanwhile I just keep expanding my search radius, asking various build system communities the OO question. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
On Sunday 16 December 2007, Brandon Van Every wrote: On Dec 16, 2007 1:11 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Waf is the offering of a fellow who clearly thinks OO is important in a build system for some reason. http://code.google.com/p/waf/ A quick eval of waf Ok, waf sucks. It can't demonstrate anything compelling about OO build systems in practice. But does it say anything about OO build systems in theory? Does the author have a good idea? Meanwhile I just keep expanding my search radius, asking various build system communities the OO question. What's the purpose ? CMake is kind-of going OO. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] too many kinds of FALSE
On Dec 16, 2007 1:44 PM, Alexander Neundorf [EMAIL PROTECTED] wrote:
On Sunday 16 December 2007, Brandon Van Every wrote:
On Dec 16, 2007 11:57 AM, David Cole [EMAIL PROTECTED] wrote:
On 12/16/07, Brandon Van Every [EMAIL PROTECTED] wrote:
What's so great about n and no ?
Nobody has claimed that they are great...
I've never used them. Do we
really need to be polluting the interpretation of strings with these
values? What current or legacy code is using them heavily?
We cannot know. We can only assume that somebody somewhere is probably
using them since they are part of how CMake currently works.
What's an example in the CMake source pool where they're actually used
for something? Or VTK or ITK? I've never had a reason to use n or
N.
n alone indeed also evaluates to false. Hmm, this really seems like a not so
good idea.
I think it sucks. -1
Try the following, this will make it always two strings:
if(${myvar} STREQUAL )
Of course now we gotta rewrite the docs to tell everyone they're not
really supposed to use the documented if(myvar STREQUAL ) because
they'll cut their fingers off. And I have to type it; you know, I
*like* not having to type extra stuff. I like if(myvar) better than
if(myvar STREQUAL ) better than if(${myvar} STREQUAL ). There's
a reason that non-CMake programmers object to jumping through these
hoops.
I'm adding the following to the list of Lua motives:
- mature corner cases
I'm willing to push CMake script towards maturity.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
Alexander Neundorf wrote: What's the purpose ? CMake is kind-of going OO. Meaning *what*, exactly? Do you mean that a) say FILE( READ ... ) will change to: File.read() or x.read() where x is a file object? and LIST( APPEND ... ) will be just a.append(x) or a += x b) you'll be able to do: class A attr_accessor :x def f( x ) @x = x + 5 end end class B A def t(); end end a = A.new a.x a.f a.x = 5 b = B.new b.x b.f b.t c) you'll have 'virtual' macros? class A def f( x ); end end class B A def f( x ) super end end a = A.new b = B.new b.f(1) # calls B::f, which in turn can call A::f, too. a.f(1) # calls A::f d) ...other... I consider a) to c) the cornerstone of OO. b and c cannot be done in cmake. a) can (only partially) be done and with an uglier syntax. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
On Sunday 16 December 2007, you wrote: Alexander Neundorf wrote: What's the purpose ? CMake is kind-of going OO. Meaning *what*, exactly? That the cmake objects (source files, targets, directories) are not only influenced by global variables, but they have their own encapsulated set of properties, which takes presedence over the global variables. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_C_FLAGS per target
Am Freitag 14 Dezember 2007 schrieb Cristian Bidea: Is it possible to set some C_FLAGS per target?! I know about the global variable CMAKE_C_FLAGS but I don't need all the flags for all the targets in the project. You can have COMPILE_FLAGS per source file (SET_SOURCE_FILES_PROPERTIES) and for all files of a target (SET_TARGET_PROPERTIES). HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] premake build system
For those who love lua and want a build system there is premake http://industriousone.com/premake And I know that there is another build system that uses lua but I can't find the link. -- Filipe Sousa signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: premake build system
Filipe Sousa escreveu: For those who love lua and want a build system there is premake http://industriousone.com/premake Look how what's on the main page (premake.sf.net): After several years of maintaining backward compatibility Or Else, I've decided it is time to make a break. And if I'm going to break compatibility I might as well go all the way and make all of the changes I've been saving up over those years. They are developing version 4.0, guess it's never too late for big changes... ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: [cmake 2.5 CVS] CMAKE_${LANG}_FLAGS is initialized with space
I've managed to debug and correct this 'bug'. The bug report is at:
http://www.cmake.org/Bug/view.php?id=6167
I really think that compiler flags should be treated like a list of
flags instead of a string because this way, IMHO, it's easier to deal
with space in flag parameters etc, to add a flag to the compiler (using
LIST(APPEND...) instead of SET(FLAG ${FLAG} -other_flag), which is ugly
and to remove a flag using LIST(REMOVE_ITEM...).
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Creation of CMAKE_*_LIBRARY_EXTENSION
I've been playing around with bug #5997 and I've found out the problem,
which lies in the fact that when the user sees the variable
CMAKE_(STATIC|SHARED|IMPORT)_LIBRARY_SUFFIX, he assumes that this is
something to be added to the library name (doesn't involve its
extension). But cmake assumes that this is the library's extension.
Wouldn't it be better to create a CMAKE_*_LIBRARY_EXTENSION to have
either '.lib' or '.a', and let CMAKE_*_LIBRARY_SUFFIX just be what its
name means? For cmake, the library name (including extension) would be:
${CMAKE_*_LIBRARY_PREFIX}${libname}${CMAKE_*_LIBRARY_SUFFIX}${CMAKE_*_LIBRARY_EXTENSION)
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
