Re: [CMake] FW: cmake newbie questions
Mike Jackson wrote: You are going to have to look through the CMake files and determine where the TEST_BIG_ENDIAN(variable) is located. Then you will need to put in some sort of conditional statement that says if you are compiling for z/OS then set variable to true. This really sounds like a cross compiler. In which case you should look here: http://www.cmake.org/Wiki/CMake_Cross_Compiling -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FW: cmake newbie questions
Phil Smith wrote: OK, next issue. I'm following (or trying to) the cross-compiler page. Since the same source tree is to be used to generate Win32 and z/OS, I think I want to tell it This is a z/OS run using a flag. I thus created zcmake.bat: cmake -DCMAKE_TOOLCHAIN_FILE:string=zos.cmake -DCMAKE_GENERATOR:internal=Unix Makefiles The reason for the second -D is because otherwise it seemed to assume Visual Studio no matter what. And since Visual Studio *is* correct when building Win32, I don't want to change the CMakeLists.txt. You should be using out of source builds. mkdir win32 cd win32 cmake -DCMAKE_TOOLCHAIN_FILE:string=../myproject/win32.cmake -GUnix Makefiles make cd .. mkdir zOS cd zOS cmake -DCMAKE_TOOLCHAIN_FILE:string=../myproject/zos.cmake -GUnix Makefiles make -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FW: cmake newbie questions
Phil Smith wrote: But then it complains that there's no CMakeLists.txt in the directory. Anyway, I wasn't clear: the same person isn't likely to be doing z/OS and Windows on the same machine. But since the same CMakeLists.txt is to be used, I didn't want to hard-code anything in there. I've changed to -G -- somehow I missed that before (I did look, honest!). You really want out of source builds. You have to give the path to the source tree. First make sure the source tree you are working on has not had cmake run on it (no CMakeCache.txt, or other generated files). Then, you do this: cmake -GUnix Makefiles ../path/to/your/source Note, the ../path/to/your/source. That is important. Now, I'm sort of inclined to declare victory for now. But should I? Are those failed messages significant? I was brought up not to ignore errors without understanding them! Failing on check size of is not a good thing, and I would track that down if I were you... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE/CTEST input test file
Edward Flanigan wrote: Using CTest, is there any way to specify what tests I want to run in a file? There is the option for -I where you have to specify the test number. I want to specify the test name (not the number): TestA TestB TestD use that file as an input to CTEST and run only the tests that were named in that file. Using numbers can lead to problems, what if more tests are added and changed the numbers of existing tests? All scripts using those numbers would have to be modified. ctest -R -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE/CTEST input test file
Edward Flanigan wrote: Date: Wed, 30 Jul 2008 17:04:03 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: cmake@cmake.org Subject: Re: [CMake] CMAKE/CTEST input test file Edward Flanigan wrote: Using CTest, is there any way to specify what tests I want to run in a file? There is the option for -I where you have to specify the test number. I want to specify the test name (not the number): TestA TestB TestD use that file as an input to CTEST and run only the tests that were named in that file. Using numbers can lead to problems, what if more tests are added and changed the numbers of existing tests? All scripts using those numbers would have to be modified. ctest -R -Bill I don't know how to make -R accept a file as an input? I have over 100 tests. I want to classify different tests with different runs of cmake. Say 50 test name stored in file test1to50 the other tests stored in tests51to100 Each file contains the names of 50 different tests. I still want flexibility to use test names (instead of numbers) because if a developer adds a new test it may change the numbering system of existing tests. Right, ctest -RTest[A-D] The -R is a regular expression. Not quite what you want, but should do the job if you name your tests with some sort of convention. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_INCLUDE_FILES
George Neill wrote:
Hi All,
I have ran into a problem on Solaris (v10/SS12) with
CHECK_INCLUDE_FILES. I believe this is actually a bug in the header
file I am checking for but none-the-less it's a problem for me. I am
using cmake 2.4.8.
CHECK_INCLUDE_FILES(netinet/tcp.h HAVE_NETINET_TCP_H)
here's a quick test program i wrote to mock up what
CHECK_INCLUDE_FILES() is doing ...
-bash-3.00$ cat test.c
#include netinet/tcp.h
int main()
{
return 0;
}
Here's the compiler results,
-bash-3.00$ cc test.c
/usr/include/netinet/tcp.h, line 40: syntax error before or at: uint_t
cc: acomp failed for test.c
It's obvious to me the netinet/tcp.h header file should have included
sys/types.h
My question is, is there a way to solve this without creating my own
check_include_files macro()?
set(CMAKE_REQUIRED_INCLUDES sys/types.h)
CHECK_INCLUDE_FILES(netinet/tcp.h HAVE_NETINET_TCP_H)
./bin/cmake --help-module CheckIncludeFiles
The following variables may be set before calling this macro to modify
the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_INCLUDE_FILES
George Neill wrote:
Bill,
I have ran into a problem on Solaris (v10/SS12) with
CHECK_INCLUDE_FILES. I believe this is actually a bug in the header
file I am checking for but none-the-less it's a problem for me. I am
using cmake 2.4.8.
CHECK_INCLUDE_FILES(netinet/tcp.h HAVE_NETINET_TCP_H)
here's a quick test program i wrote to mock up what
CHECK_INCLUDE_FILES() is doing ...
-bash-3.00$ cat test.c
#include netinet/tcp.h
int main()
{
return 0;
}
Here's the compiler results,
-bash-3.00$ cc test.c
/usr/include/netinet/tcp.h, line 40: syntax error before or at: uint_t
cc: acomp failed for test.c
It's obvious to me the netinet/tcp.h header file should have included
sys/types.h
My question is, is there a way to solve this without creating my own
check_include_files macro()?
set(CMAKE_REQUIRED_INCLUDES sys/types.h)
CHECK_INCLUDE_FILES(netinet/tcp.h HAVE_NETINET_TCP_H)
./bin/cmake --help-module CheckIncludeFiles
The following variables may be set before calling this macro to modify
the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
Well crap, I saw CMAKE_REQUIRED_INCLUDES, but read it as a -I (include
directory) not a specific file to include. I'll give that a try.
Opps, My bad... You just need to pass it in...
CHECK_INCLUDE_FILES(netinet/tcp.h;netinet/tcp.h HAVE_NETINET_TCP_H)
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MS VS 2005 nmake problem
[EMAIL PROTECTED] wrote: Hi, I am running CMake 2.6 on an XP machine with MS Visual Studio 2005 and am trying to compile VTK cvs from the Visual Studio 2005 command prompt. I am getting the following errors reported by CMake: CMake Error at CMakeLists.txt:1005 (ADD_SUBDIRECTORY): add_subdirectory not given a binary directory but the given source directory C:/C++/Source/VTK/GenericFiltering is not a subdirectory of c:/C++/Source/VTK. When specifying an out-of-tree source a binary directory must be explicitly specified. Any ideas what to do here? Looks like a drive letter case issue Can you try RC 15 for 2.6.1 and see if it has been fixed? http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-15-win32-x86.exe -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MS VS 2005 nmake problem
[EMAIL PROTECTED] wrote:
Hi Bill,
RC 15 for 2.6.1 and using C instead of c:
cmake C:/C++/Source/VTK -GNMake Makefiles
but now I have:
Checking for ipv6 support. - no
RegularExpression::compile(): Nested *?+.
RegularExpression::compile(): Error in compile.
CMake Error at Utilities/MaterialLibrary/CMakeLists.txt:94 (IF):
if had incorrect arguments: NOT ${VTK_BINARY_DIR} MATCHES
^${VTK_SOURCE_DIR}$ (Regular expression ^C:/C++/Source/VTK$ cannot
compile).
CMake Error at Utilities/MaterialLibrary/CMakeLists.txt:100 (ENDIF):
endif An ENDIF command was found outside of a proper IF ENDIF structure.
Or its arguments did not match the opening IF command.
Did ++ work in a directory name for CMake 2.4.8 and VTK?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack Stripping Debug
Paul Hatfield wrote: When compiling a binary with CMAKE_BUILD_TYPE as RelWithDebInfo, I verify that the binary has debug symbols, but when I generate an rpm using Cpack the debug symbols are lost. What's causing this? rpm automatically runs strip on executables. It is not cmake doing this but rather the rpm tools. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_INCLUDE_FILES
George Neill wrote:
Bill,
I must be missing something (or there's a bug in CheckIncludeFiles.cmake)
CHECK_INCLUDE_FILES(sys/types.h;netinet/tcp.h HAVE_NETINET_TCP_H)
SET(HAVE_NETINET_TCP_H ${HAVE_NETINET_TCP_H} CACHE INTERNAL netinet/tcp.h)
.
.
.
-- Looking for include files netinet/tcp.h
-- Looking for include files netinet/tcp.h - found
-- Looking for include files HAVE_SYS_SYSTEMINFO_H
-- Looking for include files HAVE_SYS_SYSTEMINFO_H - found
I have tried
CHECK_INCLUDE_FILES(sys/types.h;netinet/tcp.h HAVE_NETINET_TCP_H)
and
LIST(APPEND NETINET sys/types.h netinet/tcp.h)
CHECK_INCLUDE_FILES(${NETINET} HAVE_NETINET_TCP_H)
and
LIST(APPEND NETINET sys/types.h)
LIST(APPEND NETINET netinet/tcp.h)
CHECK_INCLUDE_FILES(${NETINET} HAVE_NETINET_TCP_H)
all three of these provide the same results as above (I am using 2.4.8)
I am tempted to write a macro with an interface like this,
CHECK_INCLUDES( FILES sys/types.h netinet.h VARIABLE HAVE_NETINET_TCP_H)
I suspect that might be better (for me anyhow) ... Thoughts? it
looks like the list passed in to check_include_files is getting
exploded in to three arguments.
You have to use double quotes.
From CMake/Utilities/cmcurl/CMakeLists.txt:
MACRO(CHECK_INCLUDE_FILE_CONCAT FILE VARIABLE)
CHECK_INCLUDE_FILES(${CURL_INCLUDES};${FILE} ${VARIABLE})
IF(${VARIABLE})
SET(CURL_INCLUDES ${CURL_INCLUDES} ${FILE})
ENDIF(${VARIABLE})
ENDMACRO(CHECK_INCLUDE_FILE_CONCAT)
So, this would work:
CHECK_INCLUDE_FILES(sys/types.h;netinet/tcp.h HAVE_NETINET_TCP_H)
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake 2.6.1 RC 16
I have a release candidate (RC 16) for 2.6.1 ready for CMake. If I do not get any complaints about this RC, it will become 2.6.1. Again, if there are no major issues, I am going to make this 2.6.1 official. Thanks. The files can be found here: http://www.cmake.org/files/v2.6/*RC-16* The changes from 2.6.0 are as follows: Changes in CMake 2.6.1 RC 16 - Fix for bug 7427, preinstall target name hard coded - Fix issue #7088 - do not emit error messages when attempts to run Visual Studio macros fail. You can still get the error output as messages if you want using --debug-output from the cmake command line. - Fix InstallRequiredSystemLibraries.cmake to work with win64 Changes in CMake 2.6.1 RC 15 - Fix bug 7426 FindJPEG module causes error when setting JPEG_LIBRARY to blank - Fix bug 7414 PackageMaker generator crashes when given components with circular dependencies - Fix source files to not add extra /, and look for extensions for all enabled languages. - Change link line to preserve input given to target_link_libraries even if a shared library is repeated. - Fix for bug 7421, fortran did not get arch flags on the mac - For CMP0008 do not depend on the files that are not there, which makes the Xcode generator delete executables after they are built. - Work around Boost 1.36.0 bug fix on Darwin by setting the mangled compiler name to -xgccVERSION - Updated FindImageMagick to: - Find newer additions such as animate, compare, etc. - Find development api: Magick++, MagickCore, MagickWand - Use FindPackageHandleStandardArgs to output standard messages. Changes in CMake 2.6.1 RC 14 - Change dashboard submission to go directly to CDash. - Add policy CMP0008- Full-path libraries must be a valid library file name Changes in CMake 2.6.1 RC 12 - Fix issue with .lib being seen as .obj with VS due to a full path to a library given without the file extension. This only worked with the VS generator, but some projects had worked around it with if statements. It now issues a warning, but should link. - Update cpack stuff for beta OSX bundle generator for CPack - CheckFortranFunctionExists.cmake now calls the function. - FindBLAS.cmake, FindLAPACK.cmake modules were redesigned so now you have three new variables BLA_VENDOR (you can specify the VENDOR), BLA_STATIC (gets the static version of libs), BLA_F95 (gets the fortran 95 interface). BLA_VENDOR can be specified as an environment variable. Intel mkls libs need FindThreads to be found correctly so you will need to enable the C/CXX - FindMPI: Use the HINTS feature of find_library to find the right libraries for MPI, and act a bit more intelligently when MPI cannot be found. - Improved support for finding wxWidgets in MinGW environment. - CMAKE[_SYSTEM]_(LIBRARY|PROGRAM|INCLUDE|PREFIX)_PATH variables moved CMAKE_CROSSCOMPILING from Variables that modify behaviour to variables that Provide Information - handle HTML documentation for single items better: no warning about ComputeSectionLinkPrefix, don't create an index for only one item. - Better error messages in CPackBundleGenerator Changes in CMake 2.6.1 RC 11 - Fix curl build issue with Xcode 3.1 Changes in CMake 2.6.1 RC 10 - Add a fix for bug # 7340, CMAKE_USER_MAKE_RULES_OVERRIDE was not able to support a try-compile in cmake 2.6 - Remove bad test for bug # 7316 Changes in CMake 2.6.1 RC 9 - Fix bug # 7316 Xcode double escaped define strings - FindBoost can now find the upcoming Boost 1.46 This was all in the previous public RC: Changes in CMake 2.6.1 RC 8 - Fix build problem with missing cpack file Changes in CMake 2.6.1 RC 7 - More fixes for CPack components functionality - Fixes for Xcode generater #7277 #7044, do not compile foo.txt. Rebuild application bundles when a library changes. Set the project location for Xcode 3.1 - Do not automatically add EXECUTABLE_OUTPUT_PATH to cache. - New tree view in cmake-gui - FindBoost.cmake, find boost as installed by the BoostPro/Boost Consulting installers on Windows. And cleanup FindBoost module, fixing several small bugs and providing better diagnostic information when things go wrong. - Fix FindwxWidgets.cmake to find richtext library - Fix FindQt4.cmake with empty qconfig.pri files. Fixes #7287. - Fix add/remove program version string again... - Fix column width in cmake-gui Changes in CMake 2.6.1 RC 6 - Fix DEFINITIONS property to be compatible with 2.4 - Fix escaping of $ for visual studio - FindGettext.cmake fix bug #7230: don't ignore first parameter if it's not ALL Changes in CMake 2.6.1 RC 5 - Add support for component based packages in cpack. - Fix FindBLAS.cmake if no fortran compiler is found - Fix FindFLTK.cmake to pass new module test - Fix FindKDE3.cmake to not add flags if kde3 is not found - Fix FindMatlab.cmake, FindOpenSSL.cmake, FindQt3.cmake, FindSWIG.cmake, to only error if it is required - Fix FindwxWidgets.cmake to work on msys - Add a beta OSX bundle generator for CPack
Re: [CMake] Error running link command: Argument list too long
Andrew Sayman wrote: The ChangeLogs that I can find for CMake 2.4.8 and 2.6.0 all seem to indicate that link lines being too long was fixed. Unfortunately, I'm still seeing link lines that are too long and immediately fail out because of it. Is there any place with more details on exactly *what* was done to fix it? I can't seem to find anything in the bug tracker about it, or any pages that mention it, and the FAQ is rather useless on the matter. Try 2.6.1 RC 16 and see if it is fixed. http://www.cmake.org/files/v2.6/*RC-16* What OS/Generator/Compiler are you using? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake 2.6.1 available for download
On behalf of myself, Ken, Brad, Dave, Alex and the rest of the CMake team, we are pleased to announce that CMake 2.6.1 is available for download at: http://www.cmake.org/HTML/Download.html If you have any problems or find any bugs, please report them at www.cmake.org/Bug. A list of changes for the 2.6 release tree is included below. Thanks Bill Changes in CMake 2.6.1 RC 16 - Fix for bug 7427, preinstall target name hard coded - Fix issue #7088 - do not emit error messages when attempts to run Visual Studio macros fail. You can still get the error output as messages if you want using --debug-output from the cmake command line. - Fix InstallRequiredSystemLibraries.cmake to work with win64 Changes in CMake 2.6.1 RC 15 - Fix bug 7426 FindJPEG module causes error when setting JPEG_LIBRARY to blank - Fix bug 7414 PackageMaker generator crashes when given components with circular dependencies - Fix source files to not add extra /, and look for extensions for all enabled languages. - Change link line to preserve input given to target_link_libraries even if a shared library is repeated. - Fix for bug 7421, fortran did not get arch flags on the mac - For CMP0008 do not depend on the files that are not there, which makes the Xcode generator delete executables after they are built. - Work around Boost 1.36.0 bug fix on Darwin by setting the mangled compiler name to -xgccVERSION - Updated FindImageMagick to: - Find newer additions such as animate, compare, etc. - Find development api: Magick++, MagickCore, MagickWand - Use FindPackageHandleStandardArgs to output standard messages. Changes in CMake 2.6.1 RC 14 - Change dashboard submission to go directly to CDash. - Add policy CMP0008- Full-path libraries must be a valid library file name Changes in CMake 2.6.1 RC 12 - More find locations for FindJNI. - Fix bug with source files ending in .l and .l.cpp, causing cmake to think they were the same file in some cases. - Fix issue with .lib being seen as .obj with VS due to a full path to a library given without the file extension. This only worked with the VS generator, but some projects had worked around it with if statements. It now issues a warning, but should link. - Update cpack stuff for beta OSX bundle generator for CPack - CheckFortranFunctionExists.cmake now calls the function. - FindBLAS.cmake, FindLAPACK.cmake modules were redesigned so now you have three new variables BLA_VENDOR (you can specify the VENDOR), BLA_STATIC (gets the static version of libs), BLA_F95 (gets the fortran 95 interface). BLA_VENDOR can be specified as an environment variable. Intel mkls libs need FindThreads to be found correctly so you will need to enable the C/CXX - FindMPI: Use the HINTS feature of find_library to find the right libraries for MPI, and act a bit more intelligently when MPI cannot be found. - Improved support for finding wxWidgets in MinGW environment. - CMAKE[_SYSTEM]_(LIBRARY|PROGRAM|INCLUDE|PREFIX)_PATH variables moved CMAKE_CROSSCOMPILING from Variables that modify behaviour to variables that Provide Information - handle HTML documentation for single items better: no warning about ComputeSectionLinkPrefix, don't create an index for only one item. - Better error messages in CPackBundleGenerator Changes in CMake 2.6.1 RC 11 - Fix curl build issue with Xcode 3.1 Changes in CMake 2.6.1 RC 10 - Add a fix for bug # 7340, CMAKE_USER_MAKE_RULES_OVERRIDE was not able to support a try-compile in cmake 2.6 - Remove bad test for bug # 7316 Changes in CMake 2.6.1 RC 9 - Fix bug # 7316 Xcode double escaped define strings - FindBoost can now find the upcoming Boost 1.36 Changes in CMake 2.6.1 RC 8 - Fix build problem with missing cpack file Changes in CMake 2.6.1 RC 7 - More fixes for CPack components functionality - Fixes for Xcode generater #7277 #7044, do not compile foo.txt. Rebuild application bundles when a library changes. Set the project location for Xcode 3.1 - Do not automatically add EXECUTABLE_OUTPUT_PATH to cache. - New tree view in cmake-gui - FindBoost.cmake, find boost as installed by the BoostPro/Boost Consulting installers on Windows. And cleanup FindBoost module, fixing several small bugs and providing better diagnostic information when things go wrong. - Fix FindwxWidgets.cmake to find richtext library - Fix FindQt4.cmake with empty qconfig.pri files. Fixes #7287. - Fix add/remove program version string again... - Fix column width in cmake-gui Changes in CMake 2.6.1 RC 6 - Fix DEFINITIONS property to be compatible with 2.4 - Fix escaping of $ for visual studio - FindGettext.cmake fix bug #7230: don't ignore first parameter if it's not ALL Changes in CMake 2.6.1 RC 5 - Add support for component based packages in cpack. - Fix FindBLAS.cmake if no fortran compiler is found - Fix FindFLTK.cmake to pass new module test - Fix FindKDE3.cmake to not add flags if kde3 is not found - Fix FindMatlab.cmake, FindOpenSSL.cmake,
Re: [CMake] CMake 2.6.1 available for download
Mathieu Malaterre wrote: Bill, I can reproduce my infinite dependencie problem. Every time I type 'make' it redoes the swig step, using cmake 2.4.5 I cannot reproduce the issue. How do I track this thing down ? Otherwise steps are simply: svn co https://gdcm.svn.sourceforge.net/svnroot/gdcm/trunk mkdir bla cd bla /tmp/cmake-2.6.1-Linux-i386/bin/cmake ../trunk -DGDCM_WRAP_PYTHON:BOOL=ON -DGDCM_BUILD_SHARED_LIBS:BOOL=ON exit code should be '0' now retype 'make': I'll take a look So, just curious, why not report this in one of the 16 RC's??? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.1 available for download
Mathieu Malaterre wrote: As a side note, linux user are second class citizen and AFAIK do not get automated RC build, right ? win user are simply a click away of trying RC. No, I do a full build for each RC, all platforms that are done for the release are done for the RC's. And AMD64 people (=me), are even third class citizen since they need to actually build cmake, to get the C-module loading thingy working. I am not even mentioning the special patch debian/people are applying to cmake before releasing (the /lib64 handling namely). Why do you need a 64 bit build? Doesn't the 32 bit linux build work on 64 bit? The C-module loading thing should not be used by VTK anymore. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Symbian GCC/nmake build #3
[EMAIL PROTECTED] wrote: Hello again, I'm still trying to make CMake compile my Symbian project using a gcc (GCCE) toolchain and I have some progress to report since my last posting (see http://www.cmake.org/pipermail/cmake/2008-July/022868.html BLOCKED::http://www.cmake.org/pipermail/cmake/2008-July/022868.html) as the compiler check seems to work now (but not the linker yet). My current CMake file set can be found here: https://garage.ran-dom.org/public/mixer-frans/brandneu/cmake-toolchain_files/ Because it would be a great help for me already if I could use CMake/nmake use to compile (and not yet link) I switched off the compiler test for now and the CMake configure process seems to terminate successfully. But when I run make now I get the following error message: c:\projectmake makefile:28: *** missing separator. Stop. And when I look for the corresponding lines in Makefile I find: 26: !IF $(OS) == Windows_NT 27: NULL= 28: !ELSE 29: NULL=nul 30: !ENDIF And after replacing this block manually by setting NULL to nul (it occurs another time in CMakeFiles/Makefile2) I get the following error message: c:\projectmake make.exe[1]: *** No rule to make target `/nologo'. Stop. c:\Symbian\9.2\S60_3rd_FP1\epoc32\tools\make.exe: *** [all] Error 2 Is this behaviour known? What have I done wrong? Thanks in advance, Frans make != nmake. If you want to use make then use Unix Makefiles, if you are going to use nmake, use NMake Makefiles. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.1 available for download
Hendrik Sattler wrote: Am Montag, 4. August 2008 17:48:28 schrieb Mathieu Malaterre: That was not really my main concern anyway, instead I am more concerned with the patch done for debian people (admittedly I dont understand what they are trying to do): http://ftp.de.debian.org/debian/pool/main/c/cmake/cmake_2.6.0-5.diff.gz The have /lib /lib32 - /emul/ia32-linux/lib /lib64 - /lib So adding the /lib64 to the library search will gain nothing as everything is at /lib already. The /lib64 link is only a compatibility thing for other distros that interpret the FHS in strange ways... But, does it hurt? I don't see us moving that into the main tree with the if 0 as the lib64 actually does do something on other machines. I guess we could have an if _DEBIAN_ or something like that. Or maybe we could check to see if /lib == /lib64 as other distros might do the same thing. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_TYPE_SIZE works incorrectly with LDFLAGS=-Wl, --gc-sections
Arfrever Frehtes Taifersar Arahesis wrote:
CHECK_TYPE_SIZE returns incorrect (empty) values of types sizes when
the LDFLAGS variable contains -Wl,--gc-sections.
This bug causes compilation failures in probably all packages which
use CHECK_TYPE_SIZE.
I'm attaching 2 files which help to reproduce this bug.
Steps to reproduce:
1. Save the attachments to ${PROJECT_SOURCE_DIR}
2. Run: export LDFLAGS=-Wl,--gc-sections
3. Run: cmake ${PROJECT_SOURCE_DIR}
4. Read ${PROJECT_BINARY_DIR}/config.h
I use CMake 2.6.0.
What is in the CMakeError.log? Why is it failing?
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_TYPE_SIZE works incorrectly with LDFLAGS=-Wl, --gc-sections
Arfrever Frehtes Taifersar Arahesis wrote:
2008-08-05 00:01:51 Bill Hoffman napisał(a):
Arfrever Frehtes Taifersar Arahesis wrote:
CHECK_TYPE_SIZE returns incorrect (empty) values of types sizes when
the LDFLAGS variable contains -Wl,--gc-sections.
This bug causes compilation failures in probably all packages which
use CHECK_TYPE_SIZE.
I'm attaching 2 files which help to reproduce this bug.
Steps to reproduce:
1. Save the attachments to ${PROJECT_SOURCE_DIR}
2. Run: export LDFLAGS=-Wl,--gc-sections
3. Run: cmake ${PROJECT_SOURCE_DIR}
4. Read ${PROJECT_BINARY_DIR}/config.h
I use CMake 2.6.0.
What is in the CMakeError.log?
CMakeFiles/CMakeError.log doesn't exist.
Why is it failing?
Maybe CMake uses wrong way of checking type sizes which relies on
incorrect assumptions.
I wrote steps to reproduce this bug so you should be able to confirm it.
Can you do a find in your build tree and find CMakeError.log?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_TYPE_SIZE works incorrectly with LDFLAGS=-Wl, --gc-sections
Arfrever Frehtes Taifersar Arahesis wrote: Can you do a find in your build tree and find CMakeError.log? `find -name CMakeError.log` doesn't return anything. Can you do this: cmake --debug-trycompile Then tar up and zip the whole thing and email it to me off the list. Thanks. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OS X Framework creation and DEBUG_POSTFIX
Mike Jackson wrote:
I have the following:
SET_TARGET_PROPERTIES(${MXADATAMODEL_LIB_NAME} PROPERTIES
#DEBUG_OUTPUT_NAME ${MXA_LIBRARY_RELEASE}
#RELEASE_OUTPUT_NAME ${MXA_LIBRARY_RELEASE}
FRAMEWORK TRUE
FRAMEWORK_VERSION ${MXADATAMODEL_VER}
RESOURCE
DEBUG_POSTFIX _debug
)
and when I compile in Debug mode I don't seem to get what I _think_ I
should get.
I get MXADatModel.framework/MXADataModel
I would have thought I would get MXADatModel.framework/MXADataModel_debug
Thoughts?
It was told to me by Mac experts, that the debug post fix should be
ignored for frameworks. I am pretty sure the above won't work as the
name of folder should match the name of the library. I am not sure what
the above would do for you anyway. Perhaps Eric Wing could comment
more. I think he was the one that had the request to make the debug
postfix ignored in framework creation.Eric?
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6-1 : no more GLEW support ?
Antoine PREVOT wrote: Hi, I am actually testing cmake 2.6-1, and I can't find FindGLEW.cmake anymore in the Modules folder of both darwin sources and binary archives (cmake-2.6.1.tar cmake-2.6.1-Darwin-universal.tar). Nothing about this in the ChangeLog. Bug or Feature ? :) That module was never part of CMake: $ cvs log FindGLEW.cmake cvs log: nothing known about FindGLEW.cmake It might have been part of your project, and you used CMAKE_MODULE_PATH to find it? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] some basic questions
[EMAIL PROTECTED] wrote: Hi all, I have some probably easy to answer questions, nevertheless I found no answer on the web yet. And I dont want to start separate threads because I think there will be one word only answers :) * can CMake handle multiple make processes or any other strategy to make use of multiple processors? Does that depend on the underlying build system? I use VS8, nmake and make.. Depends on the build system. nmake will not do that. For VS8, you either have to use the IDE, or use gmake with Unix Makefiles. You should install cygwin, then do not install the cygwin make, but put this one in the bin directory for cygwin: http://www.cmake.org/files/cygwin/make.exe Then make -j N should work fine. * is there a way to surpress echoing the command line instructions? I have already set CMAKE_VERBOSE_MAKEFILE to OFF but this works for me only with the Make target but not with KDevelop3 or nmake KDevelop3 turns on verbose so it can parse the output. * does anyone know a nice IDE for windows (e.g. visual studio) which can handle CMake output and cross compiling (cross compiling doesn't work for Visual Studio, does it?) You could try Eclipse. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Where does cmake look for include files?
Marianne B. Wiese wrote: Hello Just to let you know: It turns out that the way cmake looks for a file to include, is by TRY_CO)MPILE() a tiny c-file whith for example #include GL/glu.h. However, Visual C++ cannot compile with #include glu.h if windows.h is not included too. Therefore I will not succeed in compiling FLTK, unless I change checkincludefiles.cmake. You just have to add a check include for windows.h before the glu.h as that is what CONCAT part of that macro does, it will add additional includes to the check in the order they are found. I think I will give it up, and see if I can get Orfeo Toolbox to work with a binary installed FLTK instead. I am not sure what you are giving up on??? I build FLTK with cmake all the time. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking an script from the link command.
Óscar Fuentes wrote: Óscar Fuentes [EMAIL PROTECTED] writes: [snip] Solved: target_link_libraries(myexe `/path/to/script arg1 arg2`) This is in general a non-portable way to write cmake files, and is not guaranteed to work in any version of CMake. This is the same as a pkg-config script. The way to do this is to use execute_process and collect the output at cmake time, and then use target_link_libraries. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking an script from the link command.
Óscar Fuentes wrote: Bill Hoffman [EMAIL PROTECTED] writes: Solved: target_link_libraries(myexe `/path/to/script arg1 arg2`) This is in general a non-portable way to write cmake files, and is not guaranteed to work in any version of CMake. This is the same as a pkg-config script. The way to do this is to use execute_process and collect the output at cmake time, and then use target_link_libraries. I just realized another reason why your proposal is not adequate: the libraries and the script must be built before the executable, so, at cmake time, the libraries and the script does not exists. I know this is not portable, but it is intended for POSIX platforms, GNU toolchains. As far as cmake does not mess too much with the contents passed to target_link_libraries, it should be fine. Actually, CMake does not guarantee a shell at all for the link line, so back tick stuff make break even on a POSIX platform. Why does this need to be run at build time? I don't even think this will work with cmake 2.6.0, because we use link scripts. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest 'magic string' - failure
Matthew Woehlke wrote: Is there any way to arrange for running ctest to mark a test as failed if it outputs a particular string? I'm using ctest to write unit tests for a library that has some debugging facilities where if something goes wrong, it dumps an error message, but doesn't cause the function to fail, so I can't detect it in the test program. (And, no, changing the library is NOT an option.) Alternatively, there /is/ a hook to make the messages trip an abort()... is there a way to make 'make test'/'ctest' set an environment variable for all tests it runs? Or would I be stuck remembering to set it before calling 'make test'/'ctest'? You can use a test property to do that: http://www.cmake.org/HTML/cmake-2.6.html#command:set_tests_properties http://www.cmake.org/HTML/cmake-2.6.html#section_Properties%20on%20Tests -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking an script from the link command.
Óscar Fuentes wrote:
Óscar Fuentes [EMAIL PROTECTED] writes:
Bill Hoffman [EMAIL PROTECTED]
writes:
[about using shell backquotes embedded on link commands through
`target_link_libraries']
I don't even think this will work with cmake 2.6.0, because we use
link scripts.
It is working with 2.6.1 and MSYS Makefiles. Here you are doing
something like this:
cd ${CMAKE_CURRENT_BINARY_DIR} /path/to/g++.exe ...args for linking...
It doesn't work on Linux (Debian Etch x86) Unix Makefiles.
Too bad CMake is not consistent on this. Not having the possibility of
customising the command on make-time seems a serious limitation.
I think the best way for you to do this, is to override
CMAKE_CXX_LINK_EXECUTABLE in your project, and use a shell script to add
the extra stuff.
Something like this should work and be cross platform:
SET(CMAKE_CXX_LINK_EXECUTABLE ${YOUR_LINK_SCRIPT}
${CMAKE_CXX_LINK_EXECUTABLE})
Where YOUR_LINK_SCRIPT is set to a script that takes the link line as
command line arguments and adds in the the output of your command.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re-executing CMake from the Makefile.
Óscar Fuentes wrote: Currently, when `make' is executed and a CMakeList.txt file is out of date, `cmake' is automatically invoked and then `make' continues. Is it possible to do this (on a reliable way) with an arbitrary file? I need to re-execute `cmake' whenever certain file changes. I wonder if is possible to do this from `make' itself, so the user does not need to remember that he must execute `cmake' first. If the file you depend on is part of the input to cmake then cmake will do that automatically. You could use the configure_file command to do this. If you did something like this: configure_file(/my/file/input dummyout) Then when ever /my/file/input changed cmake would re-run at make time. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re-executing CMake from the Makefile.
Óscar Fuentes wrote: Bill Hoffman [EMAIL PROTECTED] writes: Óscar Fuentes wrote: Currently, when `make' is executed and a CMakeList.txt file is out of date, `cmake' is automatically invoked and then `make' continues. Is it possible to do this (on a reliable way) with an arbitrary file? I need to re-execute `cmake' whenever certain file changes. I wonder if is possible to do this from `make' itself, so the user does not need to remember that he must execute `cmake' first. If the file you depend on is part of the input to cmake then cmake will do that automatically. You could use the configure_file command to do this. If you did something like this: configure_file(/my/file/input dummyout) Then when ever /my/file/input changed cmake would re-run at make time. Will this work if /my/file/input is the output of some intermediate `make' execution? I mean: $ make # invoke make, which may modify /my/file/input at some point Will `make' invoke `cmake' on the fly and keep running with the new makefiles regenerated by `cmake'? If this is not possible, I would like to stop `make' when /my/file/output changes, possibly showing some message to the user instructing him to invoke `make' again. You could just return an error code from the command that builds the /my/file/output, that should stop make from running. All this is because /my/file/input actually is an script that is used for determining which libraries the executables depends on. The current build system builds the libraries, then the script and finally the executables. As initially it is impossible for `cmake' to stablish dependencies between libraries and executables, I wish the build to stop or restart once the script is built and re-execute cmake so it can use the script for inquiring what the dependencies are, re-generate the makefiles and continue the build. Why does the script need to be constructed at make time? Seems like you could push a bit more of the work into the script itself and all should be good. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Environment variable for a custom command
Gregory C. Sharp wrote: I found this little tidbit in the FAQ: [E]nvironment variables SET in the CMakeLists.txt only take effect for cmake itself, so you cannot use this method to set an environment variable that a custom command might need. I would like to augment the path during a custom command. Is there a suggested workaround? Run a cmake script in the custom command that runs the program via execute_process. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Environment variable for a custom command
Gregory C. Sharp wrote:
Bill Hoffman wrote:
Gregory C. Sharp wrote:
I found this little tidbit in the FAQ:
[E]nvironment variables SET in the CMakeLists.txt only take
effect for cmake itself, so you cannot use this method to set
an environment variable that a custom command might need.
I would like to augment the path during a custom command.
Is there a suggested workaround?
Run a cmake script in the custom command that runs the program via
execute_process.
OK. I might need another hint though. I try this:
MACRO(RUNME)
EXECUTE_PROCESS(...)
ENDMACRO(RUNME)
ADD_CUSTOM_COMMAND(OUTPUT output COMMAND RUNME ...)
Which yields:
1 'RUNME' is not recognized as an internal or external command
-Greg
add_custom_command(OUTPUT output COMMAND ${CMAKE_COMMAND} -S myscript.cmake)
myscript.cmake:
set(ENV{PATH} ...)
execute_process()
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Customizing manifest
? Jan wrote:
Hi,
is there any way of customizing manifest in cmake (using MSVC 2008 and
Vista)? Particularly, I need to modify requestedExecutionLevel.
If there is not such possibility, are there any plans for next versions
of cmake?
You can do something like this:
ADD_CUSTOM_COMMAND(TARGET CMakeSetup
POST_BUILD COMMAND mt
${_CMAKE_INPUT_RESOURCE}
-manifest ${CMAKE_CURRENT_SOURCE_DIR}/CMakeSetupManifest.xml
-outputresource:${exe};#1
${verbatim_flag}
)
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Make program arguments
Moreland, Kenneth wrote: Is there a way to add arguments to the invocation of make? In particular, I want to add the -j flag to do parallel compiles. I tried setting the CMAKE_MAKE_PROGRAM variable to /usr/bin/make -j8, but I get the following error when I try to compile. CMake Error: Generator: execution of make failed. Make command was: /usr/bin/make\ -j8 cmTryCompileExec/fast I'm pretty sure this used to work, but it seems to have stopped working in Cmake 2.6. I assume this is for ctest right? If the cache has: MAKECOMMAND:FILEPATH=/usr/bin/make -j 5 Then -j is used. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to make cmake-2.6 tell why it fails
Martin Costabel wrote: I am trying to help a user whose effort to build scribus-1.3.3.12 with cmake-2.6.0 on MacOSX-10.4.11 always fail with the message CMake Error at CMakeLists.txt:234 (MESSAGE): No Qt3 With the exact same configuration(?), the build runs OK for me, and I am looking for clues on how to debug this. Unfortunately, I haven't yet succeeded to have cmake give any information on why it thinks it does not find Qt3 on the user's system. The CMakeOutput.log and CMakeError.log files do not contain anything Qt3-related; they stop just before the FindQt3 module is invoked. And using the --debug-output flag does not help either; it adds absolutely nothing to the output at this point. In CVS CMake, I added a --trace option that will show each line as it is executed. You should be able to look at the users cache file and compare it with the FindQt3.cmake file. Looking at the module: IF(QT_INCLUDE_DIR AND QT_QT_LIBRARY) SET( QT_FOUND YES ) ENDIF(QT_INCLUDE_DIR AND QT_QT_LIBRARY) So, what are the values of QT_INCLUDE_DIR AND QT_QT_LIBRARY in the users CMakeCache.txt file? One of those must not be found. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to make cmake-2.6 tell why it fails
Martin Costabel wrote:
Bill Hoffman wrote:
[]
So, what are the values of QT_INCLUDE_DIR AND QT_QT_LIBRARY in the
users CMakeCache.txt file? One of those must not be found.
Indeed:
QT_INCLUDE_DIR:PATH=QT_INCLUDE_DIR-NOTFOUND
If I read the module correctly, cmake looks if the file
$ENV{QTDIR}/include/qglobal.h exists, which should in principle be the
case. I'll ask her if something is wrong with this file.
Thanks
Well, first it looks for qt.h like this:
FIND_PATH(QT_INCLUDE_DIR qt.h
[HKEY_CURRENT_USER\\Software\\Trolltech\\Qt3Versions\\3.2.1;InstallDir]/include/Qt
[HKEY_CURRENT_USER\\Software\\Trolltech\\Qt3Versions\\3.2.0;InstallDir]/include/Qt
[HKEY_CURRENT_USER\\Software\\Trolltech\\Qt3Versions\\3.1.0;InstallDir]/include/Qt
$ENV{QTDIR}/include
${GLOB_PATHS_BIN}
/usr/local/qt/include
/usr/lib/qt/include
/usr/lib/qt3/include
/usr/include/qt
/usr/share/qt3/include
C:/Progra~1/qt/include
/usr/include/qt3
)
Then, it makes sure that the path is valid by checking for qglobal.h:
# if qglobal.h is not in the qt_include_dir then set
# QT_INCLUDE_DIR to NOTFOUND
IF(NOT EXISTS ${QT_INCLUDE_DIR}/qglobal.h)
SET(QT_INCLUDE_DIR QT_INCLUDE_DIR-NOTFOUND CACHE PATH path to Qt3
include directory FORCE)
ENDIF(NOT EXISTS ${QT_INCLUDE_DIR}/qglobal.h)
Either of those could have failed...
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] command line build and install on OSX
Darren Weber wrote: On Tue, Aug 19, 2008 at 2:15 PM, Bill Hoffman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Darren Weber wrote: FYI, In case it makes any difference, I'm working on Mac OS X Leopard Server. Darwin elegans.buckcenter.org http://elegans.buckcenter.org http://elegans.buckcenter.org 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 OK, you need to run the app as root. If you used the installer package from Kitware it would automatically do that. There is not a way to create links into /usr/bin without being root. -Bill Does your installer set a sticky bit on the app to allow it to run as root? How does it enable root to run the app? The mac packager automatically does this. It is just how the .dmg works, you can create it with cpack if you want. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't compile a quite simple Fortran static library
Renato N. Elias wrote:
Hi folks,
I'm trying to use CMake 2.6 to build a Fortran static library in Visual
Studio 2005 (Fortran Intel Compiler 9.1). All files are in the same
directory.
My CMakeLists.txt file is:
#
cmake_minimum_required(VERSION 2.6)
PROJECT(edgepack_lib Fortran)
FILE(GLOB SRC_FILES *.f)
ADD_DEFINITIONS(-DASLIB)
ADD_LIBRARY(edgepack STATIC ${SRC_FILES})
#==
CMake 2.6 successfully creates the Visual Studio project but, when I hit
the build button, I get the following error message:
1-- Build started: Project: edgepack, Configuration: Debug Win32
--
1Compiling with Intel Fortran 9.1 C:\Arquivos de
programas\Intel\Compiler\Fortran\9.1\IA32\...
1..\..\src\EdgePack\block3d.f
1libifcoremt.lib(libifcoremain.obj) : error LNK2019: unresolved
external symbol _MAIN__ referenced in function _main
1block3d.exe : fatal error LNK1120: 1 unresolved externals
1
1Build log written to
file://C:\users\Renato\svn\EdgeCFD-HEAD\CMake-tests\EdgePack\Debug\BuildLog.htm
1edgepack build failed.
1
2-- Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32
--
2Project not selected to build for this solution configuration
== Build: 0 succeeded, 1 failed, 1 up-to-date, 1 skipped ==
Strange, looks like it is trying to create block3d.exe. Can you send
me the generated project files?
Thanks.
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't compile a quite simple Fortran static library
Bill Hoffman wrote: CMake 2.6 successfully creates the Visual Studio project but, when I hit the build button, I get the following error message: 1-- Build started: Project: edgepack, Configuration: Debug Win32 -- 1Compiling with Intel Fortran 9.1 C:\Arquivos de programas\Intel\Compiler\Fortran\9.1\IA32\... 1..\..\src\EdgePack\block3d.f 1libifcoremt.lib(libifcoremain.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main 1block3d.exe : fatal error LNK1120: 1 unresolved externals 1 1Build log written to file://C:\users\Renato\svn\EdgeCFD-HEAD\CMake-tests\EdgePack\Debug\BuildLog.htm 1edgepack build failed. 1 2-- Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 -- 2Project not selected to build for this solution configuration == Build: 0 succeeded, 1 failed, 1 up-to-date, 1 skipped == Strange, looks like it is trying to create block3d.exe. Can you send me the generated project files? OK Clinton tested this for me with an intel fortran compiler. He found this: 1. it worked just fine with cmake 2.6.0 2. He modified the paths in the project you generated with cmake, and that worked fine. So, we are unable to reproduce your problem. Looking at the buildlog.html that you sent me, I see this: -- Build started: Project: edgepack, Configuration: Debug|Win32 -- Compiling with Intel Fortran 9.1 C:\Arquivos de programas\Intel\Compiler\Fortran\9.1\IA32\... ifort /nologo /Zi /fpp /define:ASLIB /define:CMAKE_INTDIR=\quotDebug\ /module:quot.\Debug /object:quotedgepack.dir\Debug\\ /libs:static /threads /extfor:f /Qvc8 /Qlocation,link,quotC:\Arquivos de programas\Microsoft Visual Studio 8\VC\bin quotC:\users\Renato\svn\EdgeCFD-HEAD\src\EdgePack\block3d.f libifcoremt.lib(libifcoremain.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main block3d.exe : fatal error LNK1120: 1 unresolved externals edgepack build failed. So, it is building the static library edgepack, and compiling one of the files block3d.f, but instead of creating block3d.obj, it is trying to create block3d.exe. The only thing odd I can see is: /Qlocation,link, It should not have link options for compiling an object file. However, that does not show up in the .vfproj file at all. So, it must be some global setting that you have in your visual stduio. One difference is that Clinton is using Intel 10.1. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't compile a quite simple Fortran static library
Bill Hoffman wrote: Looking at the buildlog.html that you sent me, I see this: -- Build started: Project: edgepack, Configuration: Debug|Win32 -- Compiling with Intel Fortran 9.1 C:\Arquivos de programas\Intel\Compiler\Fortran\9.1\IA32\... ifort /nologo /Zi /fpp /define:ASLIB /define:CMAKE_INTDIR=\quotDebug\ /module:quot.\Debug /object:quotedgepack.dir\Debug\\ /libs:static /threads /extfor:f /Qvc8 /Qlocation,link,quotC:\Arquivos de programas\Microsoft Visual Studio 8\VC\bin quotC:\users\Renato\svn\EdgeCFD-HEAD\src\EdgePack\block3d.f libifcoremt.lib(libifcoremain.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main block3d.exe : fatal error LNK1120: 1 unresolved externals edgepack build failed. So, it is building the static library edgepack, and compiling one of the files block3d.f, but instead of creating block3d.obj, it is trying to create block3d.exe. The only thing odd I can see is: /Qlocation,link, It should not have link options for compiling an object file. However, that does not show up in the .vfproj file at all. So, it must be some global setting that you have in your visual stduio. One difference is that Clinton is using Intel 10.1. OK, so on the one that works we have this: ifort /nologo /Zi /fpp /DASLIB /DCMAKE_INTDIR=\Debug\ /module:.\Debug /object:edgepack.dir\Debug\\ /libs:static /threads /c /W1 /extfor:f /Qvc8 /Qlocation,link,C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\x86_amd64 C:\Users\cjstimp\fort\EdgePack\block3d.f And the one that does not work we have: ifort /nologo /Zi /fpp /define:ASLIB /define:CMAKE_INTDIR=\quotDebug\ /module:quot.\Debug /object:quotedgepack.dir\Debug\\ /libs:static /threads /extfor:f /Qvc8 /Qlocation,link,quotC:\Arquivos de programas\Microsoft Visual Studio 8\VC\bin quotC:\users\Renato\svn\EdgeCFD-HEAD\src\EdgePack\block3d.f The broken one is missing the /c which would cause the problem. The question now is where did it go?? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't compile a quite simple Fortran static library
Renato N. Elias wrote: Hi Bill, I've followed your hint and tried to create a lib with 4 routines (https://mail.nacad.ufrj.br/~rnelias/transfer/cmake/SimpleLib.zip) and the problem persists. The VS project created by CMake doesn't work at all while my hand-made project works just fine. Is there any configuration file from my Visual Studio installation that could help us in figuring out about what's happening? I am confused In SimpleLib.zip the BuildLog.htm shows: simple_lib build succeeded, also all the .obj files are there, so it seems to be working? What is the error that you get? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't compile a quite simple Fortran static library
Bill Hoffman wrote: Renato N. Elias wrote: Hi Bill, I've followed your hint and tried to create a lib with 4 routines (https://mail.nacad.ufrj.br/~rnelias/transfer/cmake/SimpleLib.zip) and the problem persists. The VS project created by CMake doesn't work at all while my hand-made project works just fine. Is there any configuration file from my Visual Studio installation that could help us in figuring out about what's happening? I am confused In SimpleLib.zip the BuildLog.htm shows: simple_lib build succeeded, also all the .obj files are there, so it seems to be working? What is the error that you get? OK, I think I get it now, the files in SimpleLib.zip are not cmake generated. Can you provide both? Also, can you make it even more simple with just one .f90 file and not 4? -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't compile a quite simple Fortran static library
Can you try this:
In the .vfproj file that works it has this:
VisualStudioProject ProjectType=typeStaticLibrary
ProjectCreator=Intel Fortran Keyword=Static Library Version=9.10
ProjectIdGuid={3963F5B6-C0D8-4C36-8503-131A2F661664}
In the one that does not work, it looks like this:
VisualStudioProject ProjectType=typeStaticLibrary
ProjectCreator=Intel Fortran Version=9.10
ProjectIdGuid={055FF2D2-F23D-4ADD-9E8C-3EDC2DAAF5E5}
Can you add this to the cmake one:
Keyword=Static Library
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BUILD_DOCUMENTATION vs. BUILD_DOXYGEN
Darren Weber wrote: What's the difference between the CMake options: BUILD_DOCUMENTATION vs. BUILD_DOXYGEN The doxygen documents the C++ code in CMake. The documentation is the cmake --help stuff. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] re-config on make all
Vandenbroucke Sander wrote: Hi, Sometimes CMake re-configures my build tree when running make. Unfortunately CMake uses wrong options, I normally set those on the command line. This forces me to re-config rebuild my entire source tree. This is a bit annoying since, in most cases, this is not necessary and takes a long time. So here is my question: can I prevent the automatic reconfiguration and throw an error/warning so the user can do a manual reconfig? CMake should use the same options. Your options should have been stored in the cache. Can you give an example of how this fails? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MEMORYCHECK_COMMAND
Andy Lego wrote: Hi, Sounds like a nice rainy Sunday project. Unfortunately it does not rain in California that much, so it is going to take a while before I have a chance to look at it. Andy On Tue, Sep 2, 2008 at 11:07 AM, Sean McBride [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 8/26/08 4:41 PM, Andy Lego said: This is a command used for memory checking, such as valgrind or purify. You do not need to set it to anything, unless you are doing memory checking during testing. I am not sure if there is any memory checker on mac at this point. Haven't looked into that for a while. Apple provides a memory tester named Guard Malloc, but CMake does not directly support it. See: http://public.kitware.com/Bug/view.php?id=4954 I have updated the bug. I made this comment: This is really not like valgrind at all. It causes your program to crash. There is no additional output that ctest would be able to parse and report on the dashboard. The man page suggests that you run the program in gdb to find out what is wrong. I suppose you could just run a regular dashboard with this library on, and if a test fails, you have a memory issue. However, I don't see how this would work with ctest. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 insists on using MSVC x64 even when in 32 bit shell
Anders Moe wrote: Thank for answering. I'm using the CmakeSetup.exe utility and interactively pick the Visual Studio 8 2005 compiler when it asks meI hope that answered the question ? The error dialog doesn't allow copy/paste, or I'd include more info. The information should be in the CMakeError.log file. If you could zip up the build tree, and post it if it is not too big, or send it to me off the list if it is, I can take a look. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake vista tutorial?
Craig Miller wrote: Thanks for the reply Alex. As a new user, I wasn't aware of the wiki and didn't think to look under the developer menu (thought it was for CMake devs, not devs using CMake). I was following the directions under http://www.cmake.org/HTML/Documentation.html. I'll take a closer look, but a quick perusal and search for vista didn't seem to offer up a tutorial. Are you suggesting that the tutorial is already there if I had only taken the time to look? As I mentioned in my other posts, I was willing to sort through and fully document any Vista related issues. At this point, I'm going to hold off on running CMake under Vista 64. While it might be possible to get it running, I'm not willing to use an immature product (under Vista 64 anyway) that has limited community support. I'll play around with it on a less critical project in a few months. Using CMake on Vista should be no different than using it on Windows XP, or Windows NT for that matter. We have developers here at Kitware that use Vista 64 on a daily basis. Do you have a specific issue? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake vista tutorial?
Craig Miller wrote: Yeah, I made a few posts last week with the details of the specific problem I'm having. A couple of folks tried to help, but in the end they were stumped too. Here's an excerpt with the meat of the problem from one of those posts: On Aug 28, 2008, at 5:04 PM, Craig Miller wrote: Mike, Thank you for the reply. Filling in the missing blanks in the tutorial, ultimately, the steps I attempted were exactly as you describe. As there doesn't seem to be a tutorial that addresses the Vista specific issues, I'll just follow the tutorial directions (same as yours) and post when I get to each specific error. I'll document what I'm doing with screenshots and when it is all working I'll provide the document to the maintainers of the website to use as they see fit. Here is where I'm at. 1.Installed cmake 2.6.1 via the Windows Installer 2. Created a CMakeLists.txt file in my src directory # Start CMakeLists.txt project(Union) add_executable(Union union.cpp) #End CMakeLists.txt 3. Fired up CMakeSetup and set the src and build directories. 4. Set the build type (nmake) 5. Received an error (picture attached). CMake Error: your RC compiler : CMAKE_RC_COMPILER-NOTFOUND was not found. Please set CMAKE_RC_COMPILER to a valid compiler path or name. (Press Cancel to suppress any further messages.) Note: Pressing cancel causes CMakeSetup to hang until Vista eventually prompts to shut it down. OK, what version of Visual Studio are you using? If it is the express version, you need to install the windows SDK. This might help: http://www.cmake.org/Wiki/CMake_Generator_Specific_Information#How_to_generate_NMake_Makefiles_using_Visual_C.2B.2B_Express_Edition_.28free_Visual_Studio_8.29 -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake vista tutorial?
Craig Miller wrote:
I'm running Visual Studio 2005 w/ SP1.
OK, so lets start from the beginning... Create a very simple project:
---CMakeLists.txt--
cmake_minimum_required (VERSION 2.6)
project(bar)
add_library(foo foo.c)
-
foo.c
int foo()
{
return 1;
}
Put those files in a directory say c:\bar
Now run CMakeSetup
- Select the source directory c:\bar
- Select the binary directory c:\bar-build
- Click Configure
- Select the Visual Studio 8 2005 generator and configure. This will
not use nmake but will test your compiler install.
- Do you get any errors?
- Load the bar.sln file from c:\bar-build into visual studio and build
- Do you get errors?
If that all works try nmake:
- Run Start- All Programs - Microsoft Visual Studio 2005 - Visual
Studio Tools - Visual Studio 2005 Command Prompt
- From the command line of the prompt you just started run:
rc /?
What is the output?
- From the command line of the prompt you just started run:
c:\Program Files\CMake 2.6\bin\CMakeSetup.exe
- Select the source directory c:\bar
- Select the binary directory c:\bar-build-nmake
- Click configure
- Click OK
- run nmake in c:\bar-build-nmake
If that does not work please post errors. There are lots of folks using
similar setups as you. Right now I suspect a bad installation of your
compiler. Did you do the default installation? Or did you customize
the installation?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake vista tutorial?
Craig Miller wrote:
Yep, a Visual Studio 2005 target works.
The output of rc /? is:
c:\users\craig\nav\maps\basemaps\installrc /?
Microsoft (R) Windows (R) Resource Compiler Version 5.2.3690.0
Copyright (C) Microsoft Corporation. All rights reserved.
c:\users\craig\nav\maps\basemaps\install
When I run the CMakeSetup via the Visual Studio command prompt, select nmake
as an output option, and press configure I get the same error message:
CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found.
Please set CMAKE_RC_COMPILER to a valid compiler path or name.
OK, so, that is all done in Modules/CMakeDetermineRCCompiler.cmake. Can
you add some message statements into that file?
It must be this line that fails for some odd reason:
FIND_PROGRAM(CMAKE_RC_COMPILER NAMES ${CMAKE_RC_COMPILER_LIST} DOC
RC compiler)
Add some message(CMAKE_RC_COMPILER_LIST = ${CMAKE_RC_COMPILER_LIST})
stuff and any other message you think might help into that file and run
again.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't compile a quite simple Fortran static library
Renato N. Elias wrote:
Bill Hoffman wrote:
Renato N. Elias wrote:
A managed to do something work (but not in the way that I'd like). In
CMake, when configuring my project, if a check the Show Advanced
Values and insert a /c in the CMAKE_Fortran_FLAGS the project works
fine.
Weird, since I'd expect CMake filling it up automatically (it's so
basic...).
OK, maybe this is the cause of your troubles:
http://public.kitware.com/Bug/view.php?id=7519
Can you remove the extra from the .vfproj file and see if it fixes
your problem?
Without the fix you get something like this:
VisualStudioProject
ProjectCreator=Intel Fortran
Version=9.10
ProjectType=typeStaticLibrary
Keyword=Static Library
ProjectGUID={30C678D0-9DFE-4608-8E2D-A374C2AA539D}
Note the extra after the ProjectType.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack, nsis and visual studio 9
Boudewijn Rempt wrote:
On Thu, 4 Sep 2008, Mathieu Malaterre wrote:
Boudewihn,
I cannot see the following line in your code:
INCLUDE(${CMAKE_ROOT}/Modules/InstallRequiredSystemLibraries.cmake)
What option did you set ?
Er. I think that was a cut pasto: I have got it:
INCLUDE(CPack)
INCLUDE(InstallRequiredSystemLibraries)
and then the rest.
Did you install service pack 1 for Visual studio 9? We have been having
some trouble with that. It seems that when you compile with VS 9 it
puts one manifest in your .exe, and the redist msvcm90.dll manifest has
a different version. One way to tell is to open your .exe file in a
text editor and find the embeded xml for the manifest. Check the
version numbers. They SHOULD match the ones in the .manifest files that
are next to the executable. Also make sure you recompile all the code
after you install the service pack.
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack, nsis and visual studio 9
Boudewijn Rempt wrote: On Thu, 4 Sep 2008, Bill Hoffman wrote: Did you install service pack 1 for Visual studio 9? Yes -- it's Visual Studio Express 9.0.30729.1 SP We have been having some trouble with that. It seems that when you compile with VS 9 it puts one manifest in your .exe, and the redist msvcm90.dll manifest has a different version. Yes, that's exactly the problem! One way to tell is to open your .exe file in a text editor and find the embeded xml for the manifest. Check the version numbers. They SHOULD match the ones in the .manifest files that are next to the executable. Also make sure you recompile all the code after you install the service pack. We're so new to this game we never ever compiled with an older version :-) Well then, I think it is a bug in Visual Studio Service pack 9! It creates executables that embed the old version of the manifest, but ships with redist manifests that are the old (pre service pack) manifests. I wonder if you did a simple text edit on the redist manifests if it would work Maybe the .dll's are correct but the .manifest files are wrong -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack, nsis and visual studio 9
Boudewijn Rempt wrote: On Thu, 4 Sep 2008, Bill Hoffman wrote: It creates executables that embed the old version of the manifest, but ships with redist manifests that are the old (pre service pack) manifests. I wonder if you did a simple text edit on the redist manifests if it would work Maybe the .dll's are correct but the .manifest files are wrong The dll and the manifest match, it's indeed the [EMAIL PROTECTED] executable that's wrong. Maybe we should splash out for a non-express version of VS... Looks like they know about it: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361682 This is in the non-express version as well. The fix seems to be to edit the manifest file by hand in the redist directory. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying directories and build error
Bo Huang wrote: After running CMake to generate Visual Studio project files, I made a copy of C:\myProj to C:\myProjCopy In this copy, I change all references of “C:\myProj” to “C:\myProjCopy” in all .cmake, .txt, and other files. I build but get this: 1Checking Build System 1CMake is re-running because CMakeFiles/generate.stamp is out-of-date. 1 CMake Error: The source /myProjCopy/CMakeLists.txt does not match the source /myProj/CMakeLists.txt used to generate cache. Re-run cmake with a different source directory. My motivation to create a copy is to avoid running CMake again. How do I get around this? You don't CMake does not support the relocation of build trees. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.2 RC 3
Sean McBride wrote: On 9/5/08 9:02 AM, Bill Hoffman said: I have a release candidate (RC 3) for 2.6.2 ready for CMake. Thanks. The files can be found here: http://www.cmake.org/files/v2.6/*RC-3* The changes from 2.6.2 are as follows: From 2.6.1 I assume? Yes. - .m compiled with gcc and g++ on mac I'm curious what this one is about... is there a bug #? Cheers, Yup: http://public.kitware.com/Bug/view.php?id=7045 -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] [Fwd: [sldev] Meet the Experts: CMake]
FYI. -Bill ---BeginMessage--- And yet another event to announce -- Please join us for a meet the experts chat with Bill Hoffman of Kitware, creators of CMake http://www.cmake.org/HTML/index.html, and Bryan O'Sullivan (Sardonyx Linden), leader of the CMake build system implementation at Linden Lab. Format will be informal QA, so bring your CMake questions. When: Open source office hour on11-Sept, 2pm PDT Where: Hippotropolis Theater http://slurl.com/secondlife/Hippotropolis/243/22/24/ This will be a voice-enabled event, and Bill and Bryan will be using the spatial voice channel. Best, Liana ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges---End Message--- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest puts LD_LIBRARY_PATH into environment impacts sub-runs of cmake/ctest
Wheeler, Frederick W (GE, Research) wrote:
CMake List:
I have a ctest/cmake issue where LD_LIBRARY_PATH must be set to run
test execs produced by ctest but that LD_LIBRARY_PATH setting causes
ctest/cmake to not run due to a library mismatch. Does anyone have a
solution or any advice? Details below.
After a recent upgrade to FreeBSD 7.0, using cmake/ctest compiled from
the FreeBSD /usr/ports using the system gcc (4.2.1), but using a
non-system gcc installed in /home/wheeler/dev/gcc-4.0.4 as the
compiler for the VXL project being built by cmake/ctest, I'm getting
errors like this when I run ctest:
/libexec/ld-elf.so.1: /home/wheeler/dev/gcc-4.0.4/lib/libstdc++.so.6:
version GLIBCXX_3.4.9 required by cmake not found
/libexec/ld-elf.so.1: /home/wheeler/dev/gcc-4.0.4/lib/libstdc++.so.6:
version GLIBCXX_3.4.9 required by ctest not found
Unable to run cmake:
/libexec/ld-elf.so.1: /home/wheeler/dev/gcc-4.0.4/lib/libstdc++.so.6:
version GLIBCXX_3.4.9 required by cmake not found
The file /home/wheeler/dev/gcc-4.0.4/lib/libstdc++.so.6 is present,
but apparently it is not version GLIBCXX_3.4.9.
In my ctest config file I use CTEST_ENVIRONMENT to set LD_LIBRARY_PATH
like you see below because that LD_LIBRARY_PATH setting is needed to
run test executables created by the ctest run. LD_LIBRARY_PATH is not
set in the environment when ctest is run initially.
SET(CTEST_ENVIRONMENT
LD_LIBRARY_PATH=/home/wheeler/dev/gcc-4.0.4/lib
CVS_RSH=ssh
http_proxy=proxy.research.ge.com:8080
FTP_PROXY=proxy.research.ge.com:8080
)
The problem seems to be that this LD_LIBRARY_PATH setting is in the
environment when ctest runs cmake and ctest (ctest running itself I
guess), and this causes those programs to not run. I think a solution
might be for ctest to put the contents of CTEST_ENVIRONMENT into the
environment when running 'make' or one of the tests, but not when it
is running cmake or ctest. This, however sounds like a difficult fix.
Not sure if this will work, but
If you used the command based ctest scripts, you have much more control
of when the env vars are set.
This came up recently in a bug report:
http://public.kitware.com/Bug/view.php?id=4954
Basically, you want something like this:
CTEST_START (Nightly)
CTEST_UPDATE (SOURCE ${CTEST_SOURCE_DIRECTORY})
CTEST_CONFIGURE (BUILD ${CTEST_BINARY_DIRECTORY})
CTEST_READ_CUSTOM_FILES(${CTEST_BINARY_DIRECTORY})
CTEST_BUILD (BUILD ${CTEST_BINARY_DIRECTORY})
SET(ENV{LD_LIBRARY_PATH} ...=)
CTEST_TEST (BUILD ${CTEST_BINARY_DIRECTORY})
CTEST_SUBMIT ()
That will use the LD_LIBRARY_PATH for just the tests. You can keep it
out of the configure step if you need to.
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[EMAIL PROTECTED]
http://www.kitware.com
518-371-3971 (phone and fax)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiler varience?
Preston A. Elder wrote: That does help a lot, but I think does not go quite far enough. As I said, there are other things that need to be done such as: - Adjusting warning levels (CMAKE_WARN_LEVEL=(None|Full|Standard) ) - Forcing a 32-bit or 64-bit compile - Allowing for platform-specific builds if possible (ie. don't maintain i386 compatibility, compile specifically for i686). Most of these can be done in all supported compilers, but the flags for doing so are different per-compiler. Since the Platform directory exists (thanks for pointing it out, I didn't see it before), is there any thoughts on an effort to expand this to more than just optimization and debug flags? I can not seem to find the bug entry, but there is a long term goal of having a more feature based set of options. Things like CMAKE_WARN_LEVEL. Brad King might want to comment more on this, but the short answer is yes, but it is a ways off. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest puts LD_LIBRARY_PATH into environment impacts sub-runs of cmake/ctest
Wheeler, Frederick W (GE, Research) wrote:
Thanks for this helpful tip, which is panning out well, though I'm still
testing/fixing a few things. I have a few follow-up questions, and I'm
grateful for any advice on any of them from anybody.
1. What is the right way to add a notes file when ctest-scripting like
this? Is there a script equivalent of the command-line option ctest -A
Notes.txt ? Or does -A Notes.txt still need to be on the ctest
command-line?
SET (CTEST_NOTES_FILES
${CTEST_SCRIPT_DIRECTORY}/${CTEST_SCRIPT_NAME})
2. Does it make sense to use both CTEST_TEST() *and* CTEST_MEMCHECK()
for valgrind builds? I've always just done one of the other, but cannot
remember why.
Yes it does, they are separate operations. If you do not run
ctest_test(), then you will get an empty test column on the dashboard.
3. There used to be a file $BLDTREE/Testing/TAG that had the date
string (e.g. 20080909-1705) of the most recent output directory used
by ctest. I've been checking for the presence of
$BLDTREE/Testing/string_taken_from_TAG/Configure.xml to determine
whether a continuous ctest build just the a CVS update and found no
changes, or did a CVS update and then did a build/test/submit. My
reason is that if a continuous build actually does something I want to
trigger dependent builds (other cmake projects), but not otherwise. So
my question is this: if I'm right that TAG is now gone, how can I
determine whether a continuous build actually did build. Hmmm. I guess
I could use CTEST_UPDATE( SOURCE \${CTEST_SOURCE_DIRECTORY}
RETURN_VALUE res ) and write a file or not based on 'res'. Is that the
right thing to do here?
Using res is the right thing to use for that.
For example, I have a paraview derivative project that does this:
function(update_and_build_paraview)
# first update paraview
message(update and build ParaView)
execute_process(COMMAND
c:/Program Files/TortoiseCVS/cvs.exe
update -dAP
WORKING_DIRECTORY c:/Dashboards/My Tests/ParaView3)
ctest_build (BUILD c:/Dashboards/My Tests/ParaView3VS8Nightly)
endfunction(update_and_build_paraview)
ctest_empty_binary_directory (${CTEST_BINARY_DIRECTORY})
while (${CTEST_ELAPSED_TIME} LESS 36000)
set (START_TIME ${CTEST_ELAPSED_TIME})
ctest_start (Continuous)
ctest_update (SOURCE ${CTEST_SOURCE_DIRECTORY} RETURN_VALUE res)
# force a build if this is the first run and the build dir is empty
if(NOT EXISTS ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt)
set(res 1)
message(first time build)
file(WRITE ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt
ParaView_DIR:PATH=${CTEST_DASHBOARD_ROOT}/ParaView3VS8Nightly
)
endif(NOT EXISTS ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt)
if(${res} GREATER 0)
message(Found changes run build)
update_and_build_paraview()
ctest_configure (BUILD ${CTEST_BINARY_DIRECTORY})
ctest_read_custom_files(${CTEST_BINARY_DIRECTORY})
ctest_build (BUILD ${CTEST_BINARY_DIRECTORY})
ctest_test (BUILD ${CTEST_BINARY_DIRECTORY})
ctest_submit ()
endif(${res} GREATER 0)
# loop no faster than once every 5 minutes
message(wait for 5 minutes)
ctest_sleep( ${START_TIME} 300 ${CTEST_ELAPSED_TIME})
endwhile(${CTEST_ELAPSED_TIME} LESS 36000)
4. With my older ctest command-line runs, continuous builds used to
automatically end if there were no changes during the CVS update. Is
that still true with these ctest scripts? My guess is no, and you need
to check the RETURN_VALUE of CTEST_UPDATE and take care of this yourself
by putting the rest of the steps in an IF/ENDIF. Is that right?
See the above while loop.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CVS write access for module maintainers
Matt Leotta wrote: Hi, I'm a new module maintainer and I've just join this list as well. I've filled out the web form to get a developer account, and Mantis now lists me as a developer. How do I check out the modules from CVS for read/write access? I haven't been able to fine the appropriate cvs command on the website or the wiki. Could someone fill me in, or better yet, post it on the wiki? I will handle that off the list. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to add a test and compare its output to a reference file ?
Judicaël Bedouet wrote:
Hi,
I 'm converting a project to CMake. Tests in this project print messages
to cout and these output traces are compared to reference files. If
output and its reference are different, the corresponding test is
considered as failed. I can't see how to make these tests work with CMake.
I try to run a complex command in ADD_TEST like
ADD_TEST (Test test --arg_test output ${DIFF_COMMAND} output
reference_file).
DIFF_COMMAND is equal to diff under Unix and fc under Windows. But CMake
interprets test commands and '' is passed as an argument to test
(test --arg_test output diff output reference_file).
I try to set property PASS_REGULAR_EXPRESSION to contents of reference
file. It works for little files but it's difficult for large files :
- All characters * . ( ) ^ $ ... must be backslashed.
- In this project, generated files are encoded in UTF-8 and I'm not
sure that CMake regular expressions support UTF-8.
- When there is a difference, I can't see where it is. I understand
that PASS_REGULAR_EXPRESSION wasn't thought in terms of matching whole file.
I could modify source of program tests by redirecting std::cout to a
file and comparing this file to the reference file. But before doing
this, I would like to know if there is a way to make a test with command
like `test args file diff` or if it's possible to add a test
property which compare output of the program to a no regular expression.
You can do something like this:
ADD_TEST(MyTestCreate Test test --arg_test --output output)
ADD_TEST(MyTestCreateCompare ${CMAKE_COMMAND} -E compare_files output
outputTest)
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Small, realistic Cpack example
Boudewijn Rempt wrote: On Tue, 16 Sep 2008, Stephen Collyer wrote: Does anyone know of/have a realistic cpack example showing packaging of 3rd party libraries, as well as those built from the install target ? If the third party libraries happened to include Qt, that'd be just fine .. Ah... Well, we're struggling with that ourselves at the moment, and looking in vain some good examples. Right now, we're using CPack for Linux and Windows, and have stopped using CPack for OS X -- where I am right now writing a shell script to fill out the .app bundle and create a dmg out of it, following E. Wing's advice last weekend. You can look at CMake itself. The new QtDialog in particular packages Qt with the cmake gui. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make -j and cmake
Jim Chaney wrote: Although the version of make available on the cmake website seems to work OK from the command line, when I then run it under Incredibuild (to move from parallel to distributed builds) I get a crash inside make.exe. I have spoken to Xoreax (the makers of Incredibuild) and they are interested but unable to assist, as the problem is inside make and not their product. The logical step then was to make my own debug version of make from the source, but I cannot get the same behaviour from a locally compiled make (using latest CVS as downloaded from Savannah) as I do with the version from the cmake website. So to the questions: 1) What modifications were made to the CVS of make? Is there a certain date I should sync to? (I notice that it says the -j option only takes effect for that call to make, and subsequent calls have to have -j added to them; I dont think the cmake generated makefile will do this for me, will it?) The fix allowed for C:/ to be a valid path. It had nothing to do with -j. Current CVS should have the fix, I don't have a date. 2) When I get 'valid' source, what parameters were used in the config.h? Most importantly, was HAVE_CYGWIN_MAKE or HAVE_MKS_MAKE defined? It was built as cygwin. You might want to look at this: http://sites.google.com/a/rwalker.com/cygwin/make-381-DOS It has the source as well. Apologies of this seems tangential, but unless I am misunderstanding the CVS repository make hasn't been released for 2+ years so the change from Bill has never been released... That is a cygwin issue. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] multi-line definitions
cyril_wobow wrote:
Have you tried the following
SET (CMAKE_C_FLAGS_RELEASE -mcpu=arm7tdmi -std=gnu99
-fgnu89-inline ... -DNDEBUG)
Cyril
That won't work. It will create a list of items and it needs to be a
big string.
The only way would be something like this:
set(a -mcpu=arm7tdmi -std=gnu99 -fgnu89-inline -finline-functions)
set(a ${a} -ffunction-sections -fdata-sections )
set(a ${a} -fno-strict-aliasing -mno-thumb -Os -fomit-frame-pointer)
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] multi-line definitions
Hendrik Sattler wrote: Am Thursday 18 September 2008 15:18:46 schrieb Bill Hoffman: cyril_wobow wrote: Have you tried the following SET (CMAKE_C_FLAGS_RELEASE -mcpu=arm7tdmi -std=gnu99 -fgnu89-inline ... -DNDEBUG) Cyril That won't work. It will create a list of items and it needs to be a big string. Exactly why is it not possible to give a cmake list of options to property like COMPILE_FLAGS and LINK_FLAGS? CMake kindof should know that those flags cannot be given as e.g. -Wall;-W. Or is there any known case where this would make sense? Just an oversight. Brad has something in CVS CMake that will allow this. But, for all released versions of CMake, this is how it is. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Regenerating Visual Studio projects
Jesper Eskilson wrote: Hi all, When CMake (2.6) discovers that a CMakeLists.txt file has changed, and that one or more Visual Studio projects/solutions need to be reloaded, it attempts to interrupt the build, force Visual Studio to reload the projects, and then restart the build. This is really good compared to CMake 2.4, where the projects weren't reloaded until the build had completed and you possibly had to build again from scratch. I have a problem, though: CMake does not properly detect if it is being run from inside Visual Studio, and it doesn't check that it interrupting the correct Visual Studio instance. Say that you have a studio instance opened on a solution. If I run CMake to regenerate a completely different solution, CMake will try to interrupt the (unrelated) studio instance. This wouldn't be too bad unless Visual Studio kept throwing up interactive dialogs asking do you really want to interrupt the build and do you want to reload 78 project files. I have users who needs to run my build scripts (which invoke cmake) without the script interfering with any other studio instances they may have running. Either CMake should detect that it is being run under Visual Studio and attempt to stop/interrupt the studio instance which it was started by, or there should be a flag to disable any form of communication with Visual Studio as in CMake 2.4). Which brings me to my second issue: when CMake is rerun from inside Visual Studio, I have to click on at least 3 interactive dialogs in order for the project to be reloaded. Is there anything CMake can do about that? I don't want to click on any dialogs at all, just have the project files recreated and reloaded. Please create a bug report about this issue. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Customizing target locations with VS generator
Armin Berres wrote: On Wed, 17 Sep 08 12:28, cyril_wobow wrote: This is great but I would really love to find a way to remove that $(OutDir) from the way, so that all my targets are put into the same directory, not depending on the build config. There is no possible filename clash since all my targets have different suffixes. Is there a simple solution to my problem? I have exactly the same issue. I'd love to see a solution for this problems, because it is a bit nasty to work around this manually. If you did that, you would have to remove the ability to build multiple configurations at the same time. You might be better off using nmake. There are ways to deal with the config directory, but you really do need it if you are going to use that IDE and be able to specify debug or release from the IDE. I know it is a bit foreign to a unix developer, but even Xcode has the same notion of a config directory. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake 2.6.2 RC 5
I have a release candidate (RC 5) for 2.6.2 ready for CMake. I think this one will be it for 2.6.2, so speak now or forever hold your peace... :) Thanks. The files can be found here: http://www.cmake.org/files/v2.6/*RC-5* The changes from 2.6.2 to 2.6.1 are as follows: Changes in CMake 2.6.2 RC 5 - Add beta BundleUtilities.cmake file - CPackRPM 7435 fixes to add optional post-install - Fix Bug #7456, FindBoost versioned find not working - Fix FindCurses to be able to work without ncurses.h - FindQt4 fix bug #7433, add a bit more documentation and add ability to specify extra flags to lupdate. Changes in CMake 2.6.2 RC 4 - Fix bug #7359 make llvm-gcc work, by explicitely excluding llvm- from _CMAKE_TOOLCHAIN_PREFIX - Fix bug 7046: OS X Framework support: extensionless headers were being ignored when specified as public headers - Fix documentation in CheckCCompilerFlag.cmake - Add better version support to find_package command - Fix Xcode debug not working - Add VERSION compare to if command - Make FindThreads sete THREADS_FOUND - Deb cpack generator sets Installed-Size for the package - Do not add an empty /D at the end of VS 6 .dsp compile lines - Recognize /MAP in VS 7 and greater - Add new policy CMP0009 - GLOB_RECURSE should not follow symlinks by default Changes in CMake 2.6.2 RC 3 - Fix bug, and remove extra closing in visual fortran projects. - Fix bug in ctest -C where it was sometimes ignored. - Fix crash with exec_process when cmake is being debugged on windows - Fix unsetting of global properties Changes in CMake 2.6.2 RC 2 - allow tool chains to limit object path length - add info.plist to frameworks - better preservation of user link lines - add a get command for cmake policies - support for imported libraries of unknown type - support link interface in target_link_libraries - Do not hang when select lies - .m compiled with gcc and g++ on mac - Fix issue when application bundle dir is removed cmake needs to re-run automatically - Report an error when configure has one error - Fix bug where -E commands stole command line options - Fix infinite recursion bug with try-compile and change of compilers - Fix delete and backspace in ccmake - Fix coverage not to follow symlinks - Add more possible languages for NSIS in cpack - FindQt4.cmake fix bug #7433, add documentation that directories also can be specified to update the translation files. - Add standard arg handling to FindPHP4.cmake - Add X11R6 to search path for FindOpenGL - update cmake-syntax.vim to have more keywords - BUG: fix #7477, set VERBOSE=1 in the kdevelop setting for the environment, not together with the make executable - UsePkgConfig.cmake - clean up, add a status message in case pkgconfig didn't find the package, sync with kde - FindX11 look in more places - FindTIFF look for more names - FindQt3, make sure qt4 is not found and some style stuff - FindPNG add more names of linpng (sync with the KDE version) - FindKDE3/KDE4 sanity checks on qt versions found - FindLibXMl2 also search for xmllint, which comes with libxml2 (sync with FindLibXml2.cmake from KDE) - Fix sizeof, and other compiler INFO string checks with GNU linker's --gc-sections - Fix bogus dependency on executable targets when a linked library happended to match the name of an executable target - Improve readability of circular depends error - Fix crash on circular target dependencies - find_package now knows about lib64 paths - Fix gentoo elf security issue with RPATH and RUNPATH Changes in CMake 2.6.2 RC 1 - Fix abort in eclipse generator with empty EXECUTABLE_OUTPUT_PATH - Fix FindKDE3.cmake syntax error - Fix custom command output by relative path not always working - Fix bug, Do not convert RPATH entries to full path. - Allow for $ORIGIN into the RPATH - Allow for static libraries with lots of objects using archive append - Fix documentation for FindImageMagick.cmake - Fix link error with MS compiler and comdef - Fix crash when attempting to load the RPATH out of a non-ELF file - Add --trace option to cmake allowing for the tracing of a cmake run - Fix for issue #4971 where the case of the drive letter component of the filenames might be different when analyzing gcov output. - Add warning level W0 to visual studio - Add support for OSX library version flags -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.2 RC 5
Alan W. Irwin wrote: On 2008-09-22 13:56-0400 Bill Hoffman wrote: I have a release candidate (RC 5) for 2.6.2 ready for CMake. I think this one will be it for 2.6.2, so speak now or forever hold your peace... :) Could we have a fix for the enable_language bug #4772? I don't know the CMake code well enough to send a patch, but my first guess is there is some #ifdef screwup since the problem occurs on Linux but apparently not on Windows. I can try. I don't think it is a simple ifdef problem. The initialization stuff is pretty tricky with enable language. I don't think this has ever worked in any version of CMake has it? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.2 RC 5
Mike Jackson wrote: Any chance of getting Bug 6195 put into this release. This is an important bug/feature for OS X users. Sorry, that will have to wait until 2.6.3. Too much of a new feature. There are some issues with 2.6.1 that really need to be fixed so that some existing projects will work with CMake 2.6. I am only interested in regressions at this point. Basically stuff that used to work in 2.4, or worked in 2.6.1 that is broken for 2.6.2 will get fixed at this point. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find_library feature request
Christopher Harvey wrote: Hello list, I was wondering if a better way to handle failed find_library under windows would be to give the user a chance to manually find the package before giving an error. I know the user always has the chance to specify the path afterwards in the GUI, but I think that for users that are new to CMake it may be slightly intimidating to get error messages if find_library fails. I think it would be a good idea to add a new find_library option that would turn on user intervention when find package fails that would pop up a file picker dialog with a custom message like select the root boost directory, eg. boost_1_26. I think this would be most helpful under windows when running in the gui dialog. I would prefer to use the gui. That is exactly what it is for. The project should be able to customize warnings and give proper instruction to the user. I don't want the command line cmake to pop anything up on windows or any os. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.2 RC 5
Alan W. Irwin wrote: Never mind since you indicated in your answer to Mike you were only interested in fixing newly introduced bugs for this release, and this CMake bug has been around a long time. On the other hand it is bad when a clear and obvious bug like this one persists for a long time after the initial report so I hope you will be able fix it in CVS and release it for the next release. Only so much time in the day. :) And, this bug is a bit of a corner case. Most projects just enable all the languages as the top of the project. In this case, no one could have a project that depends on this working because it never worked. However, I will try to get to it soon. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Early Registration Ends Sept. 30th!
Kitware is pleased to announce the next Developer's Training Week for VTK, ITK, ParaView and CMake, which will be held November 3-6, 2008 in Clifton Park, NY. Course details are provided below and online at http://www.kitware.com/products/protraining.html. Early Registration ends September 30th. Please contact [EMAIL PROTECTED] with any questions. Details -- The Developer's Training Week will cover our open-source projects including VTK, ITK, ParaView and CMake. These hands-on courses are appropriate for both new users wishing to quickly gain proficiency and experienced developers requiring advanced customization skills. The Developer’s Training Week is a great opportunity to meet some of the key contributors to these open-source projects as well as other users in the open source community. The course runs Monday through Thursday, from 9am to 5pm. The course schedule is: Software Overview: Monday AM This session provides an introduction to VTK, ITK, ParaView, and CMake, and an overview of the open source communities, products, and services that support these projects. VTK Track 1: Monday PM through Tuesday PM Targeted for beginners, this session provides a basic understanding of the VTK pipeline mechanism and the rendering subsystem. Attendees are led through detailed examples to quickly gain a working knowledge of the visualization and data processing capabilities of VTK for various data types. VTK Track 2: Monday PM through Tuesday PM This session covers advanced topics in VTK including custom filter writing, information visualization, multi-block and composite data handling, time support, interaction and widgets, and parallel data processing. CMake / CDash / CTest: Wednesday AM Learn how you can use the open-source software process tools employed by VTK, ITK, and ParaView in order to quickly and easily build and test your own software projects in a heterogeneous computing environment. ITK: Wednesday PM through Thursday PM This session covers the basic architecture of ITK, the use of its image segmentation and image registration algorithms, the methods used for interfacing ITK to VTK, and the common techniques for integrating ITK into existing applications. ParaView: Wednesday PM through Thursday PM The first part of this session offers an introduction to ParaView from a user's perspective, providing you with the knowledge necessary to effectively process and visualize your data. The second part of the course is geared toward developers who would like to create custom functionality and incorporate it into ParaView. As a course attendee, you will receive: - Books / course notes for the sessions you attend - Snacks and lunch daily - A dinner reception on both Monday and Wednesday evening The Registration Fees for the Developer's Training Week are: On or before September 30th: - $2500 for the four days or - $750 per day After September 30th: - $3000 for the four days or - $900 per day No prior experience is necessary; however, attendees will need to have basic knowledge of C or C++ in order to fully participate in the interactive exercises. Kitware courses incorporate both technical presentations and practical exercises designed to reinforce learning. Each attendee should bring their own laptop computer to the courses. Approximately two weeks before the course, attendees will receive detailed instructions on how to download, install and test all necessary software on their laptop computer. Any remaining issues will be resolved on-site during the Software Overview session on Monday morning. The course registration form can be found at http://www.kitware.com/products/protraining.html. Additional information is available by emailing [EMAIL PROTECTED] or by calling 518-371-3971. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.2 RC 5
Alan W. Irwin wrote: On 2008-09-22 16:44-0400 Bill Hoffman wrote: [...]this bug is a bit of a corner case. Most projects just enable all the languages as the top of the project. In this case, no one could have a project that depends on this working because it never worked. However, I will try to get to it soon. Thanks, Bill, for giving this bug #4772 fix a soon priority since it does directly impact PLplot users. ENABLE_LANGUAGE is a necessity for PLplot since we have multiple optional language bindings. (If we put, e.g., Fortran in our PROJECT statement, we would exclude all our users that don't have a Fortran compiler available even if they didn't care about those particular language bindings for PLplot.) As a result of this bug I have had to recommend to our PLplot users that they should not use build types (which depend on the compiler flags that are not correctly set as a result of this ENABLE_LANGUAGE bug) and instead specify compiler flags directly using, e.g., FC='gfortran -g' I look forward to your bug fix which should make build types work properly for the first time on the Linux platform for PLplot (and all other projects that use ENABLE_LANGUAGE). Another approach might be to use enable_language(languageName OPTIONAL). Would this work: enable_language(Fortran OPTIONAL) project(myproject C CXX) It would always test for fortran, and enable it if they have it. If they do not have it, then you can just turn off that binding. It won't be an error not to have it. If they do have it you can offer the binding option for Fortran. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.2 RC 5
Alan W. Irwin wrote: enable_language(Fortran OPTIONAL) project(myproject C CXX) It would always test for fortran, and enable it if they have it. If they do not have it, then you can just turn off that binding. It won't be an error not to have it. If they do have it you can offer the binding option for Fortran. In fact, I have been considering moving to that approach since it should give a smoother user experience. However, that consideration doesn't affect the principal issue which is that our current approach and the above approach still must use ENABLE_LANGUAGE for optional languages like Fortran. This means the ENABLE_LANGUAGE bug kicks in for Fortran, the Fortran compiler flags are not set properly in the cache for PLplot, and build types do not work properly for the Fortran binding of PLplot (on the Linux platform). Did you try what I suggested? I am thinking if you have the enable_language BEFORE the project command it will get around the bug, and work as you want it to. I have not tested, but I think if it comes before project it should work. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Additional testing of bug #4772
Alan W. Irwin wrote: i.e., the only pattern that gives the correct result is one that does not use ENABLE_LANGUAGE. I did all the above tests with 2.6.0, but previously I have shown the CVS version of CMake had similar problems. OK, thanks for trying it. I noticed that you only test with C/CXX. Does the same thing happen with Fortran? I think some of the C stuff gets initialized by CXX and CXX by C. However, Fortran should for the most part be separate. My guess is the fix will go in the Platform directory. If you have a C only project does it create empty CXX vars that are not used? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Additional testing of bug #4772
Alan W. Irwin wrote: Bill, can you or someone else from Kitware take over now to finish this off? If you don't have immediate access to Linux, I am willing to do any experiments you suggest on that platform. Currently, I feel I am floundering around close to the solution of the problem on my own, but I think it will require somebody with more comprehensive CMake language support expertise than mine to determine a really elegant solution for this Platform bug that works not only for C, but also for CXX in the Linux gcc case. So, as you can see it is not a simple ifdef. This could take some time to fix, or it might be quick. The initialization of compilers is a very tricky part of CMake, and changes often break things in hard to detect ways. We have plenty of linux machines, just not plenty of time... It is on the list of things todo. One thing that might help you understand what is going on, is the new --trace option. It will show you every statement and file cmake includes. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compute Node Linux (CNL)
John Biddiscombe wrote: I downloaded a tarball of 2.6.1 and tried ./configure on one of the cray test machines, it fails to compile cmake with the following Linking C shared module libcmsysTestDynload.so /opt/xt-asyncpe/1.0c/bin/cc: INFO: linux target is being used /usr/bin/ld: /usr/lib64/libpthread.a(pt-system.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/libpthread.a: could not read symbols: Bad value make[2]: *** [Source/kwsys/libcmsysTestDynload.so] Error 2 make[1]: *** [Source/kwsys/CMakeFiles/cmsysTestDynload.dir/all] Error 2 make: *** [all] Error 2 I tried wiping everything and experimenting with various flags such as ./configure -static but no success. 1) Is it possible to tell cmake to configure and not use any shared libs 2) Has anyone had any success with CNL. I googled a little but did not turn up anything useful. Ultimately, I'd like to try compiling paraview batch mode under CNL. That is just a test. You might want to try make -k, most of cmake does not require shared stuff. However, I don't think we have an option to turn off all shared stuff yet. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compute Node Linux (CNL)
John Biddiscombe wrote: Bill That is just a test. You might want to try make -k, most of cmake does not require shared stuff. However, I don't think we have an option to turn off all shared stuff yet. Good spot. OK. cmake has built itself now. I should have realized that the fail was on one of the tests. Bad though, because if libpthread can't be linked against by shared libs, I won't have any chance of creating plugins for paraview. cmake is running now, so I can at least play. You might want to move this over to the paraview developers list. I know paraview was cross compiled onto a cray Xt3 machine, and there are ways to build it without any shared stuff. See http://vtk.org/Wiki/Cross_compiling_ParaView3_and_VTK -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] the switch to subversion?
Mike Arthur wrote: On Tuesday 23 September 2008 16:19:05 Michael Wild wrote: git rocks! ;-) I agree but not everyone is happy using the console for their VCS. You move to git and you alienate said people. Subversion, on the other hand, has a lots of GUI tools available for such folks. Lets not have the git/cvs/svn discussion we had in January... Here is the thread if someone wants to read it: http://www.cmake.org/pipermail/cmake/2008-January/018976.html We (Kitware) have issues with moving to svn (or any other VCS) because of the way we have abused cvs. We use symbolic links on the server side to share kwsys with several projects. To date we have not yet found a good way to do this from svn. git is pretty much a show stopper because of the poor windows support it currently has. However, I have been told that git can easily track an svn repository. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] the switch to subversion?
Mathieu Malaterre wrote: svn 'external' links to repositories (not tested). Do not know what is the default behavior for branching... Yup, but there are issues with that. For one thing you can not do an atomic commit from the top of the tree and have it go into the sub project correctly. From here: http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html The support that exists for externals definitions in Subversion remains less than ideal, though. ... And Subversion still truly operates only on nondisjoint working copies. So, for example, if you want to commit changes that you've made in one or more of those external working copies, you must run svn commit explicitly on those working copies—committing on the primary working copy will not recurse into any external ones. Also, it would mean converting ITK, VTK, ParaView and CMake all at the same time So what we need is a way to bridge CVS to SVN until all projects have been moved. And we need to figure out a way to deal with the external stuff in a way that works. Basically, it is a bunch of work for us to move... I am not saying we won't, but there are still details to work out. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake 2.6.2 RC 6
I have a release candidate (RC 6) for 2.6.2 ready for CMake. There is one small fix over RC 5. I fixed cpack so it would run from a symlink, which fixes the command line install on Mac OSX when the application bundle is used. If there are no issues by the morning I will do a release tomorrow. Thanks. The files can be found here: http://www.cmake.org/files/v2.6/*RC-5* The changes from 2.6.2 to 2.6.1 are as follows: Changes in CMake 2.6.2 RC 6 - Fix bug#7669 cpack did not work when sym-linked after install Changes in CMake 2.6.2 RC 5 - Add beta BundleUtilities.cmake file - CPackRPM 7435 fixes to add optional post-install - Fix Bug #7456, FindBoost versioned find not working - Fix FindCurses to be able to work without ncurses.h - FindQt4 fix bug #7433, add a bit more documentation and add ability to specify extra flags to lupdate. Changes in CMake 2.6.2 RC 4 - Fix bug #7359 make llvm-gcc work, by explicitely excluding llvm- from _CMAKE_TOOLCHAIN_PREFIX - Fix bug 7046: OS X Framework support: extensionless headers were being ignored when specified as public headers - Fix documentation in CheckCCompilerFlag.cmake - Add better version support to find_package command - Fix Xcode debug not working - Add VERSION compare to if command - Make FindThreads sete THREADS_FOUND - Deb cpack generator sets Installed-Size for the package - Do not add an empty /D at the end of VS 6 .dsp compile lines - Recognize /MAP in VS 7 and greater - Add new policy CMP0009 - GLOB_RECURSE should not follow symlinks by default Changes in CMake 2.6.2 RC 3 - Fix bug, and remove extra closing in visual fortran projects. - Fix bug in ctest -C where it was sometimes ignored. - Fix crash with exec_process when cmake is being debugged on windows - Fix unsetting of global properties Changes in CMake 2.6.2 RC 2 - allow tool chains to limit object path length - add info.plist to frameworks - better preservation of user link lines - add a get command for cmake policies - support for imported libraries of unknown type - support link interface in target_link_libraries - Do not hang when select lies - .m compiled with gcc and g++ on mac - Fix issue when application bundle dir is removed cmake needs to re-run automatically - Report an error when configure has one error - Fix bug where -E commands stole command line options - Fix infinite recursion bug with try-compile and change of compilers - Fix delete and backspace in ccmake - Fix coverage not to follow symlinks - Add more possible languages for NSIS in cpack - FindQt4.cmake fix bug #7433, add documentation that directories also can be specified to update the translation files. - Add standard arg handling to FindPHP4.cmake - Add X11R6 to search path for FindOpenGL - update cmake-syntax.vim to have more keywords - BUG: fix #7477, set VERBOSE=1 in the kdevelop setting for the environment, not together with the make executable - UsePkgConfig.cmake - clean up, add a status message in case pkgconfig didn't find the package, sync with kde - FindX11 look in more places - FindTIFF look for more names - FindQt3, make sure qt4 is not found and some style stuff - FindPNG add more names of linpng (sync with the KDE version) - FindKDE3/KDE4 sanity checks on qt versions found - FindLibXMl2 also search for xmllint, which comes with libxml2 (sync with FindLibXml2.cmake from KDE) - Fix sizeof, and other compiler INFO string checks with GNU linker's --gc-sections - Fix bogus dependency on executable targets when a linked library happended to match the name of an executable target - Improve readability of circular depends error - Fix crash on circular target dependencies - find_package now knows about lib64 paths - Fix gentoo elf security issue with RPATH and RUNPATH Changes in CMake 2.6.2 RC 1 - Fix abort in eclipse generator with empty EXECUTABLE_OUTPUT_PATH - Fix FindKDE3.cmake syntax error - Fix custom command output by relative path not always working - Fix bug, Do not convert RPATH entries to full path. - Allow for $ORIGIN into the RPATH - Allow for static libraries with lots of objects using archive append - Fix documentation for FindImageMagick.cmake - Fix link error with MS compiler and comdef - Fix crash when attempting to load the RPATH out of a non-ELF file - Add --trace option to cmake allowing for the tracing of a cmake run - Fix for issue #4971 where the case of the drive letter component of the filenames might be different when analyzing gcov output. - Add warning level W0 to visual studio - Add support for OSX library version flags ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Error: The source directory ./build/CMakeFiles/CMakeTmp does not exist.
Roger Martin wrote: Hi, I'm trying to build a build with cmake-2.6.1-win32-x86 CMakeSetup for Visual Studio 9 2008 Win64 as the build target. Keep getting a --- CMake Error: The source directory ./build/CMakeFiles/CMakeTmp does not exist. Specify --help for usage, or press the help button on the CMake GUI. --- but when I look, the directory is there; it does exist. Got the nightly build to see what could be the problem or if the issue has already been caught and fixed. Yet get the same issue trying to setup the build for cmake [Was also going to try to compile cmake for 64 bit machines]. The project root is ./ and the build folder is ./build. Could this be some sort of path length issue? What is .? Also, can you build a very simple project: c:/foo/CMakeLists.txt add_library(foo foo.c) Run CMakeSetup and set source to c:/foo and build to c:/foo/build. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Error: The source directory ./build/CMakeFiles/CMakeTmp does not exist.
Roger Martin wrote: Setting the full path fixes it. I'm wondering, on relative paths, if the cmake home/bin directory is the root. Yes, ./ is the current directory of the project from where I run a cmd script. With the paths fixed as you pointed out, I then get an error dialog with ... The C compiler C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/amd64/cl.exe is not able to compile a simple test program. ... But by hand-build-environment, I can compile and link a 64 bit program with cl.exe and the Windows SDK I use Netbeans and Visual C++ 2008 Express IDE's. But for some complex projects such as http://www.openscenegraph.org CMake is the right tool. I am still not quite following what works for you and what does not work for you. Can you describe when the ./ does not work and what steps you take? Also, for the compiler not working, can you give the full error message? If possible send the CMakeCache.txt and the CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log files. You do have to run CMake from an environment that works. So, running CMakeSetup from the start menu may cause trouble if the global PATH and env is not correct. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Error: The source directory ./build/CMakeFiles/CMakeTmp does not exist.
Roger Martin wrote: The project consists entirely of configurations that require support for platforms which are not installed on this machine. The project cannot be loaded. The project consists entirely of configurations that require support for platforms which are not installed on this machine. The project cannot be loaded. This sounds like the problem. What if you do not build for 64 bits. It sounds like your compiler is not setup to build 64 bit apps. Does it work if you pick the other visual studio generator that is not 64 bits? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problems with cmake, visualstudio generator and add_library / target_link_libraries
Thomas Veith wrote: Hi *, when using a simple CMakeLists.txt like the following: cmake_minimum_required(VERSION 2.6) PROJECT(socket) add_definitions( -D_CRT_SECURE_NO_WARNINGS ) add_library(socket STATIC ../../src/base64.cpp ../../src/http.cpp ../../src/PoolThread.cpp ../../src/ResourceHandler.cpp ../../src/socket.cpp ../../src/sslsocket.cpp ) target_link_libraries(socket ws2_32.lib ) CMake does not link anything to static libraries. However, if you later do something like this: add_executable(foo foo.cpp) target_link_libraries(foo socket) Then foo will link to socket and ws2_32. You should not get undefined symbols from the creation of a static library. Linking static libraries to static libraries is not portable (can't even do it on other platforms). You might want to try some windows pragma magic in your code if you want to do something like this. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problems with cmake, visualstudio generator and add_library / target_link_libraries
Thomas Veith wrote: Hi Bill, Thanks a lot! I did add_executable(foo foo.cpp) add_dependencies(foo socket) and wasnt aware that I also need target_link_libraries(foo socket) Now it works! Actually, you don't need that add_dependencies call either. That is only needed to force something to build before something else that it does not link to. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmakesetup launch discrepancy
Aleksander Demko wrote: The commands: cmakesetup \src\mysource and cmakesetup c:\src\mysource seem to do different things under XP (Cmake 2.6.1). The first version loads the last source/build directories, while the second version does the right thing: loads mysource as the source and . as the build. Is this a bug or is there something more subtle here? It is a bug, but really it should be: cmakesetup src . with cmake.exe you always have to specify the binary directory explicitly. That change may not have made it into cmakesetup. What does cmake-gui do? At the end of the day, CMakeSetup will go away and be replaced with cmake-gui. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake 2.6.2 available for download
On behalf of myself, Ken, Brad, Dave, Alex and the rest of the CMake team, we are pleased to announce that CMake 2.6.2 is available for download at: http://www.cmake.org/cmake/resources/software.html If you have any problems or find any bugs, please report them at www.cmake.org/Bug. A list of changes for the 2.6 release tree is included below. Thanks Bill Changes in CMake 2.6.2 RC 6 - Fix bug#7669 cpack did not work when sym-linked after install Changes in CMake 2.6.2 RC 5 - Add beta BundleUtilities.cmake file - CPackRPM 7435 fixes to add optional post-install - Fix Bug #7456, FindBoost versioned find not working - Fix FindCurses to be able to work without ncurses.h - FindQt4 fix bug #7433, add a bit more documentation and add ability to specify extra flags to lupdate. Changes in CMake 2.6.2 RC 4 - Fix bug #7359 make llvm-gcc work, by explicitely excluding llvm- from _CMAKE_TOOLCHAIN_PREFIX - Fix bug 7046: OS X Framework support: extensionless headers were being ignored when specified as public headers - Fix documentation in CheckCCompilerFlag.cmake - Add better version support to find_package command - Fix Xcode debug not working - Add VERSION compare to if command - Make FindThreads sete THREADS_FOUND - Deb cpack generator sets Installed-Size for the package - Do not add an empty /D at the end of VS 6 .dsp compile lines - Recognize /MAP in VS 7 and greater - Add new policy CMP0009 - GLOB_RECURSE should not follow symlinks by default Changes in CMake 2.6.2 RC 3 - Fix bug, and remove extra closing in visual fortran projects. - Fix bug in ctest -C where it was sometimes ignored. - Fix crash with exec_process when cmake is being debugged on windows - Fix unsetting of global properties Changes in CMake 2.6.2 RC 2 - allow tool chains to limit object path length - add info.plist to frameworks - better preservation of user link lines - add a get command for cmake policies - support for imported libraries of unknown type - support link interface in target_link_libraries - Do not hang when select lies - .m compiled with gcc and g++ on mac - Fix issue when application bundle dir is removed cmake needs to re-run automatically - Report an error when configure has one error - Fix bug where -E commands stole command line options - Fix infinite recursion bug with try-compile and change of compilers - Fix delete and backspace in ccmake - Fix coverage not to follow symlinks - Add more possible languages for NSIS in cpack - FindQt4.cmake fix bug #7433, add documentation that directories also can be specified to update the translation files. - Add standard arg handling to FindPHP4.cmake - Add X11R6 to search path for FindOpenGL - update cmake-syntax.vim to have more keywords - BUG: fix #7477, set VERBOSE=1 in the kdevelop setting for the environment, not together with the make executable - UsePkgConfig.cmake - clean up, add a status message in case pkgconfig didn't find the package, sync with kde - FindX11 look in more places - FindTIFF look for more names - FindQt3, make sure qt4 is not found and some style stuff - FindPNG add more names of linpng (sync with the KDE version) - FindKDE3/KDE4 sanity checks on qt versions found - FindLibXMl2 also search for xmllint, which comes with libxml2 (sync with FindLibXml2.cmake from KDE) - Fix sizeof, and other compiler INFO string checks with GNU linker's --gc-sections - Fix bogus dependency on executable targets when a linked library happended to match the name of an executable target - Improve readability of circular depends error - Fix crash on circular target dependencies - find_package now knows about lib64 paths - Fix gentoo elf security issue with RPATH and RUNPATH Changes in CMake 2.6.2 RC 1 - Fix abort in eclipse generator with empty EXECUTABLE_OUTPUT_PATH - Fix FindKDE3.cmake syntax error - Fix custom command output by relative path not always working - Fix bug, Do not convert RPATH entries to full path. - Allow for $ORIGIN into the RPATH - Allow for static libraries with lots of objects using archive append - Fix documentation for FindImageMagick.cmake - Fix link error with MS compiler and comdef - Fix crash when attempting to load the RPATH out of a non-ELF file - Add --trace option to cmake allowing for the tracing of a cmake run - Fix for issue #4971 where the case of the drive letter component of the filenames might be different when analyzing gcov output. - Add warning level W0 to visual studio - Add support for OSX library version flags Changes in CMake 2.6.1 RC 16 - Fix for bug 7427, preinstall target name hard coded - Fix issue #7088 - do not emit error messages when attempts to run Visual Studio macros fail. You can still get the error output as messages if you want using --debug-output from the cmake command line. - Fix InstallRequiredSystemLibraries.cmake to work with win64 Changes in CMake 2.6.1 RC 15 - Fix bug 7426 FindJPEG module causes error when setting JPEG_LIBRARY to blank - Fix bug 7414 PackageMaker generator
Re: [CMake] [New Module] Protocol buffers
Mike Arthur wrote: On Thursday 25 September 2008 17:36:52 Bill Hoffman wrote: Please see here: snip New modules added to the bug tracker are generally ignored. Patches for existing ones are assigned to the maintainer. It would be nice if you could send the above links and close the bug instead rather than ignoring them. I realise its more work (also feeling the pain of a customer bug tracker here) but its infinitely more helpful. Ignore is a bit strong on my side, however, you are right I should close new module ones, and give the links. I will do that at some point. http://www.cmake.org/Bug/view.php?id=7691 This has a very simple patch but no comments or assignments and, as far as I can tell from the above links, the module is maintained by Kitware. I have updated http://www.itk.org/Wiki/CMake:Module_Maintainers for FindQt4. I have also assigned the bug. I did post all my modules that I posted to the bug tracker to this mailing list too. I didn't put [New Module] in the subject line or attach the files, instead linking to the attachment in the bugtracker. Should I redo this? No. Do you want to maintain them? If so, send me an email off the list. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unix Makefiles can not find some project files
Mike Jackson wrote: I started down the path of using Unix Makefiles on Windows. Here is what I have done so far. I downloaded the GnuWin32 files to my PC. I edited the .bat file that launches GnuWin32 shell and added the Visual Studio 2008 vsvars.bat file. I open a new GnuWin32 shell and type cl.exe and get the compiler. Great. I launch cmake-gui.exe from this same shell to get Cmake up and create a new build directory selecting Unix Makefiles as my generator. Everything configures and generates without errors. I start compiling and my main library compiles fine but the when the first test starts to compile I get the following: [ 80%] Building CXX object Testing/CMakeFiles/BmpIOTest.dir/BmpIOTest.obj cd C:/Workspace/MXADataModel/Build/Testing C:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /D _DEBUG /MDd /Zi /Ob0 /Od /RTC1 -IC:/Workspace/MXADataModel/src -IC:/Workspace/MX ADataModel/Build -IC:/Developer/VS9/boost/include/boost-1_36 -IC:/Developer/VS9/ expat/include -IC:/Developer/VS9/hdf5-166/include -IC:/Developer/VS9/tiff/includ e -DMXA_BUILT_AS_DYNAMIC_LIB /TP /FoCMakeFiles/BmpIOTest.dir/BmpIOTest.obj /Fd C:/Workspace/MXADataModel/Build/Bin/BmpIOTest.pdb -c C:/Workspace/MXADataModel/s rc/Testing/BmpIOTest.cpp The system cannot find the path specified. make[2]: *** [Testing/CMakeFiles/BmpIOTest.dir/BmpIOTest.obj] Error 1 make[2]: Leaving directory `C:/Workspace/MXADataModel/Build' make[1]: *** [Testing/CMakeFiles/BmpIOTest.dir/all] Error 2 make[1]: Leaving directory `C:/Workspace/MXADataModel/Build' make: *** [all] Error 2 Not sure what is wrong. I use cygwin which uses a bash shell. I of course use my patched version of gmake. I do have not tried the tools with GnuWin32. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Dependent Libraries added automatically?
Mike Jackson wrote:
I started noticing some warnings when I am linking my project
executables that bascially says libraries are listed multiple times on
the link line. Now this is just a warning so I _could_ ignore it but I
am curios about how cmake is working at this point. Here is what I have:
Library MXADataModel built by CMake.
It depends on Expat, Tiff and HDF5 (which are installed on the local
filesystem and NOT build by cmake).
I have some Examples that are built in the same project as the
MXADataModel library. Lets take one of those examples as and example..
SET (DATAIMPORT_EXAMPLE_SOURCES
${MXA_SOURCE_DIR}/src/Examples/DataImport/main.cpp
${MXA_SOURCE_DIR}/src/Examples/DataImport/SimpleImportExample.cpp
${MXA_SOURCE_DIR}/src/Examples/DataImport/ExampleImportDelegate.cpp
${MXA_SOURCE_DIR}/src/Examples/DataImport/ExampleImportDelegateFactory.cpp
)
SET (DATAIMPORT_EXAMPLE_HEADERS
${MXA_SOURCE_DIR}/src/Examples/DataImport/SimpleImportExample.h
${MXA_SOURCE_DIR}/src/Examples/DataImport/ExampleImportDelegate.h
${MXA_SOURCE_DIR}/src/Examples/DataImport/ExampleImportDelegateFactory.h
)
source_group(src\\Examples\\DataImport FILES
${DATAIMPORT_EXAMPLE_SOURCES} ${DATAIMPORT_EXAMPLE_HEADERS})
ADD_EXECUTABLE(DataImportExample ${DATAIMPORT_EXAMPLE_SOURCES})
TARGET_LINK_LIBRARIES(DataImportExample ${MXADATAMODEL_LIB_NAME} )
MXADATAMODEL_LIB_NAME is the name of the MXADataModel library that is
built earlier in the project and has dependencies on hdf5, tiff and expat.
If I use the code as is then cmake will actually add the tiff, hdf5 and
expat libraries to the link line. Is CMake _supposed_ to do that? This
is building shared libraries and tiff, expat and hdf5 are all dylibs
also. Building MXADataModel as a static library shows the same behavior.
This is on OS X 10.5.5 with Xcode 3.1.x tooling generating Makefiles.
Same thing using Xcode generated targets. So maybe I just don't
understand how linking works on OS X?
Just wondering if I make changes to the CMake files will it mess up
windows builds?
Yes, cmake automatically chains this stuff.
add_library(a ...)
target_link_library(a b c)
add_executable(foo ...)
target_link_libraries(foo a)
This will cause foo to link to a b c.
With CMake 2.6.2 you can stop this from happening with a target property:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Dependent Libraries added automatically?
Michael Jackson wrote: add_library(a ...) target_link_library(a b c) add_executable(foo ...) target_link_libraries(foo a) This will cause foo to link to a b c. With CMake 2.6.2 you can stop this from happening with a target property: http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LINK_INTERFACE_LIBRARIES -Bill And just to be clear this will work on all platforms, all compilers? Yes, it should. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: Fwd: cmake link against Qt4's OpenGL
Linge Bai wrote: It is the moc stuff that's causing the problem. After used qmake to generate moc_*.cpp files, I was able to use cmake to compile the code. But I still have no idea on how to use cmake to compile the code without using qmake to generate the moc files first. The change to my CMakeLists.txt file I made is: SET(QT_WRAP_CPP TRUE) See here: http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindQt4 Specifically: There are also some files that need processing by some Qt tools such as moc and uic. Listed below are macros that may be used to process those files. macro QT4_WRAP_CPP(outfiles inputfile ... OPTIONS ...) create moc code from a list of files containing Qt class with the Q_OBJECT declaration. Per-direcotry preprocessor definitions are also added. Options may be given to moc, such as those found when executing moc -help. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_CURRENT_SOURCE_DIR for modules
James Bigler wrote: Sure, but how can I do this from within FindMyPackage.cmake? Leave off the .cmake. include(extrastuff) should work if CMAKE_MODULE_PATH is set correctly. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] win32 wrongly set on linux when using subdirectories
Stephen Sinclair wrote: Hi, This is strange. I'm using CMake on Fedora Core 9. I have a few .c files that should only be included when my project is compiled on Windows, but for some reason it was including them on Linux. I paired this down to a minimal example that goes wrong. It seems that my subdirectory has the WIN32 variable set for some reason, while the top level directory does not. If I cd to the subdirectory, it works fine. Same thing happens using SUBDIRS instead of ADD_SUBDIRECTORY. $ cmake --version cmake version 2.6-patch 1 $ cat CMakeLists.txt cmake_minimum_required(VERSION 2.6) PROJECT(MyProj C) ADD_SUBDIRECTORY(src) $ cat src/CMakeLists.txt cmake_minimum_required(VERSION 2.6) if(WIN32) message(FATAL_ERROR windows detected wrongly) endif(WIN32) $ cmake . CMake Error at src/CMakeLists.txt:4 (message): windowsdetectedwrongly -- Configuring done $ cd src/ $ cmake . -- Configuring done -- Generating done -- Build files have been written to: /home/ssteve/project/src I am unable to reproduce this. [EMAIL PROTECTED]:~/testit/b$ ~/cmake-2.6.1-Linux-i386/bin/cmake .. -- The C compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done hello from subdir -- Configuring done -- Generating done -- Build files have been written to: /home/hoffman/testit/b Where did you get the cmake binary? Try the one from http://www.cmake.org/cmake/resources/software.html You don't need to be root to install, just untar anywhere and use a full path to cmake. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding a library on Windows
Moritz Moeller wrote:
FIND_LIBRARY(3DELIGHT_LIBRARY NAMES 3Delight PATH $ENV{DELIGHT}/lib)
MESSAGE(STATUS ${3DELIGHT_LIBRARY})
It is PATHS not PATH. You told it to look for a library that might be
named 3Delight, PATH or C:/Program Files/3Delight/lib.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
