[CMake] Crash running CMake on Windows
Hello, as one of the maintainers of the PLplot package I have been experimenting with CMake on Windows. I used the pre-built stable Windows version (downloaded it last week). When I start CMake and ask it to build the project files for MSVC++ 6.0, the configuration works fine. When, however, I want to generate the actual project files, the program crashes when (apparently) 32% is ready. One of those message boxes comes up stating that the MFC application I am using has fouled up. It does leave a lot of dsp/dsw files in the build directory, but I can not be sure the collection is complete. Building the package fails, but that is probably due to the CMake rules witin PLplot being under development. Any advice? What more information do you need? Kind regards, Arjen Markus ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Different behaviour of LIBRARY_OUTPUT_PATH?
Hi,
I've set my LIBRARY_OUTPUT_PATH to
SET(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/plugins)
to distinct between debug and release build on win32. This works fine with
nmake makefiles but fails with vcproj. The output path is
${CMAKE_BINARY_DIR}/plugins/${CMAKE_BUILD_TYPE} then ...
Imho this worked fine with 2.4.2.
Christian
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Different behaviour of LIBRARY_OUTPUT_PATH?
At 05:57 AM 8/8/2006, Christian Ehrlicher wrote:
Hi,
I've set my LIBRARY_OUTPUT_PATH to
SET(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/plugins)
to distinct between debug and release build on win32. This works fine with
nmake makefiles but fails with vcproj. The output path is
${CMAKE_BINARY_DIR}/plugins/${CMAKE_BUILD_TYPE} then ...
Imho this worked fine with 2.4.2.
In vcproj CMAKE_BUILD_TYPE is always empty, but it always puts files in
the configuration directory (Debug, Release, MinSizeRel, etc.). This has
not changed between 2.4.2 and 2.4.3 it has been this way for many years.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Different behaviour of LIBRARY_OUTPUT_PATH?
Von: William A. Hoffman [EMAIL PROTECTED]
At 05:57 AM 8/8/2006, Christian Ehrlicher wrote:
Hi,
I've set my LIBRARY_OUTPUT_PATH to
SET(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/plugins)
to distinct between debug and release build on win32. This works fine
with nmake makefiles but fails with vcproj. The output path is
${CMAKE_BINARY_DIR}/plugins/${CMAKE_BUILD_TYPE} then ...
Imho this worked fine with 2.4.2.
In vcproj CMAKE_BUILD_TYPE is always empty, but it always puts files in
the configuration directory (Debug, Release, MinSizeRel, etc.). This has
not changed between 2.4.2 and 2.4.3 it has been this way for many years.
I just thought it worked with 2.4.2.
So no chance to get it in another directory than the config dir with .vcproj?
Christian
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] A little patch for FindQt4.cmake
Hi,
I have writen a little patch for FindQt4.cmake. The patch simply do one
thing, it read library linking flags from *.prl file under QTDIR/lib.
The reason that I create this patch is that, FindQt4 do not set all the
linking flags (e.g. -lXinerama etc.) required by qt application. I hope
this patch can be useful for somebody. The linking flags found in *.prl
files are stored in QT_LIBRARIES, maybe the script should be modified to
store them in separated variables, for example, flags from libQtCore.prl
should be stored in QT_QTCORE_LIBRARY etc.
cheers,
Limin
*587a588,618*
SET(QT_LIBRARIES )
# This macro reads linking flags from .prl file, and add them to QT_LIBRARIES.
# It will do nothing, if the file do not exist.
MACRO( QT_LINK_FLAGS_FROM_PRL FILENAME )
SET( FILE_PRL NOTFOUND )
FIND_FILE( FILE_PRL ${FILENAME} $ENV{QTDIR}/lib )
IF( FILE_PRL )
# Read .prl file:
FILE( READ ${FILE_PRL} LIB_QTGUI_PRL )
# Extract the line with linking flags:
STRING( REGEX MATCH QMAKE_PRL_LIBS.+ PRL_LINE
${LIB_QTGUI_PRL} )
# Split the line by whitespaces:
STRING( REGEX MATCHALL [^ \t\n]+ PRL_LINK_FLAGS ${PRL_LINE} )
# Remove items which are not linking flags:
LIST( REMOVE_ITEM PRL_LINK_FLAGS QMAKE_PRL_LIBS = )
# Remove flags from QT_LIBRARIES, if they are presented in
PRL_LINK_FLAGS:
LIST( REMOVE_ITEM QT_LIBRARIES ${PRL_LINK_FLAGS})
# Add flags from PRL_LINK_FLAGS to QT_LIBRARIES:
LIST( APPEND QT_LIBRARIES ${PRL_LINK_FLAGS} )
ENDIF( FILE_PRL )
ENDMACRO( QT_LINK_FLAGS_FROM_PRL )
*605a637,663*
QT_LINK_FLAGS_FROM_PRL( libQtCore.prl )
QT_LINK_FLAGS_FROM_PRL( libQtCore_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtGui.prl )
QT_LINK_FLAGS_FROM_PRL( libQtGui_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQt3Support.prl )
QT_LINK_FLAGS_FROM_PRL( libQt3Support_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtAssistantClient.prl )
QT_LINK_FLAGS_FROM_PRL( libQtAssistantClient_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtDesigner.prl )
QT_LINK_FLAGS_FROM_PRL( libQtDesigner_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtDesignerComponents.prl )
QT_LINK_FLAGS_FROM_PRL( libQtDesignerComponents_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtMain.prl )
QT_LINK_FLAGS_FROM_PRL( libQtMain_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtMotif.prl )
QT_LINK_FLAGS_FROM_PRL( libQtMotif_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtNetwork.prl )
QT_LINK_FLAGS_FROM_PRL( libQtNetwork_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtNsplugin.prl )
QT_LINK_FLAGS_FROM_PRL( libQtNsplugin_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtOpenGL.prl )
QT_LINK_FLAGS_FROM_PRL( libQtOpenGL_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtSql.prl )
QT_LINK_FLAGS_FROM_PRL( libQtSql_debug.prl )
QT_LINK_FLAGS_FROM_PRL( libQtXml.prl )
QT_LINK_FLAGS_FROM_PRL( libQtXml_debug.prl )
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Different behaviour of LIBRARY_OUTPUT_PATH?
Christian Ehrlicher wrote: So no chance to get it in another directory than the config dir with .vcproj? I wouldn't try it as multiple configurations inside one build tree need these IntDir subdirectories. See CMAKE_CONFIGURATION_TYPES Jan. -- Dipl.-Ing. Jan Woetzel -- University of Kiel Institute of Computer Science and Applied Mathematics Hermann-Rodewald-Str. 3 [room 310] 24098 Kiel/Germany -- Phone +49-431-880-4477 Fax +49-431-880-4845 Mob. +49-179-2937346 -- Url www.mip.informatik.uni-kiel.de/~jw Email [EMAIL PROTECTED] ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] C# news?
Brad King wrote: Currently there are no plans to develop support ourselves to my knowledge. If someone volunteers to add it we will accept the contribution. If you want to do this we can get you started. Thanks for the info, However, I will stick to my custom commands for now. Jan -- Dipl.-Ing. Jan Woetzel -- University of Kiel Institute of Computer Science and Applied Mathematics Hermann-Rodewald-Str. 3 [room 310] 24098 Kiel/Germany -- Phone +49-431-880-4477 Fax +49-431-880-4845 Mob. +49-179-2937346 -- Url www.mip.informatik.uni-kiel.de/~jw Email [EMAIL PROTECTED] ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] libraries
I'm a newbie to cmake and am running CMake 2.4.2 on WinXP, using the
command line tools from MS's 2005 toolkit.
my directories look like
c:\pkg\c\cmake\my\s - lib sources
|\o - build dir. for my.lib - static
wh-\o- app build - my build directory
\s- app sources
All seems to work as expected, except I cannot get cmake to find the
library directly.
If I add the path to it to the environment variable LIB, the link step
completes properly.
Any hints or help would be most appreciated.
TIA
My cmakelists.txt file in wh\s
---
Project( which )
ADD_EXECUTABLE( which which )
INCLUDE_DIRECTORIES( ${WHICH_SOURCE_DIR} c:\\my\\h )
SET (CMAKE_VERBOSE_MAKEFILE ON)
OPTION( WHICH_DEBUG
Build for debugging
ON )
#LINK_DIRECTORIES( ${WHICH_BINARY_DIR}/../../my/o )
#LINK_DIRECTORIES( c:\\pkg\\c\\cmake\\my\\o )
#LINK_DIRECTORIES( c:/pkg/c/cmake/my/o )
FIND_LIBRARY( MY_LIB NAMES my MY PATHS c:\\pkg\\c\\cmake\\my\\o
c:/pkg/c/cmake/my/o )
# None of the above let nmake find the necessary lib
#link in the support libray
TARGET_LINK_LIBRARIES( which my )
-
The output from running nmake:
==
C:\pkg\c\cmake\wh\ocmakesetup
C:\pkg\c\cmake\wh\oc:\program files\cmake 2.4\bin\cmakesetup.exe
C:\pkg\c\cmake\wh\ocmake ../s
-- Configuring done
-- Generating done
-- Build files have been written to: C:/pkg/c/cmake/wh/o
C:\pkg\c\cmake\wh\onmake
Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Program Files\CMake 2.4\bin\cmake.exe -HC:\pkg\c\cmake\wh\s
-BC:\pk
g\c\cmake\wh\o --check-build-system CMakeFiles\Makefile.cmake 0
C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe -f
CMakeFi
les/Makefile2 /nologo - all
C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe -f
CMakeFi
les\which.dir/build.make /nologo -L
CMakeFiles\which.dir\depend
C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe -f
CMakeFi
les\which.dir/build.make /nologo -L
CMakeFiles\which.dir\build
Linking C executable which.exe
C:\Program Files\CMake 2.4\bin\cmake.exe -P
CMakeFiles\which.dir\cmake
_clean_target.cmake
C:\PROGRA~1\MICROS~3\VC\bin\cl.exe /nologo
@C:\DOCUME~1\arnold\LOCALS~1
\Temp\nm2.tmp
LINK : fatal error LNK1104: cannot open file 'my.lib'
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC\bin\cl.exe' : return
code '0
x2'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
8\VC\BIN\n
make.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
8\VC\BIN\n
make.exe' : return code '0x2'
Stop.
C:\pkg\c\cmake\wh\o
==
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Crash running CMake on Windows
At 08:23 AM 8/8/2006, William A. Hoffman wrote: At 02:53 AM 8/8/2006, Arjen Markus wrote: Hello, as one of the maintainers of the PLplot package I have been experimenting with CMake on Windows. I used the pre-built stable Windows version (downloaded it last week). When I start CMake and ask it to build the project files for MSVC++ 6.0, the configuration works fine. When, however, I want to generate the actual project files, the program crashes when (apparently) 32% is ready. One of those message boxes comes up stating that the MFC application I am using has fouled up. Any advice? What more information do you need? Found the problem and fixed it in CVS: Unrestricted user: hoffman /cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v -- cmLocalGenerator.cxx new revision: 1.144; previous revision: 1.143 /cvsroot/CMake/CMake/Source/cmLocalGenerator.h,v -- cmLocalGenerator.h new revision: 1.62; previous revision: 1.61 The problem comes up when using FORTRAN from vs IDE projects. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] libraries
[EMAIL PROTECTED] wrote:
FIND_LIBRARY( MY_LIB NAMES my MY PATHS c:\\pkg\\c\\cmake\\my\\o
c:/pkg/c/cmake/my/o )
You don't need the backslash version. CMake always uses forward slashes
in its own scripts.
#link in the support libray
TARGET_LINK_LIBRARIES( which my )
You have to use the result of the FIND_LIBRARY:
TARGET_LINK_LIBRARIES( which ${MY_LIB} )
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] A little patch for FindQt4.cmake
From: Fu Limin [EMAIL PROTECTED] Subject: [CMake] A little patch for FindQt4.cmake Hi, I have writen a little patch for FindQt4.cmake. The patch simply do one thing, it read library linking flags from *.prl file under QTDIR/lib. The reason that I create this patch is that, FindQt4 do not set all the linking flags (e.g. -lXinerama etc.) required by qt application. I hope this patch can be useful for somebody. The linking flags found in *.prl files are stored in QT_LIBRARIES, maybe the script should be modified to store them in separated variables, for example, flags from libQtCore.prl should be stored in QT_QTCORE_LIBRARY etc. cheers, Limin Hi, I was just about to do the same thing :) However, yesterday, I came across some Qt documentation saying that the .prl files are of an internal format and Trolltech reserves the right to change the format whenever they want. So, instead, I was going to read the mkspecs/qconfig.pri file to get the Qt configuration options (x11sm, freetype, xrandr, xinerama, etc...). Based on that, do some FIND_LIBRARY calls using library paths specified by qmake. Does that sound like a better approach? Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to add capability to generate preprocessed and not-yet-compiled files ?
Alexander Neundorf wrote: Attached is a first try of a patch against 2.4 branch. It introduces two new variables CMAKE_CREATE_PREPROCESS_RULES and CMAKE_CREATE_ASSEMBLE_RULES. I think especially the name CMAKE_CREATE_ASSEMBLE_RULES is not good (since actually everything except assembling is done). The created files are named foo.o.E and foo.o.S (was easier than to replace the suffix. I know only the compiler switches for gcc, so I added them only in gcc.cmake. I've committed changes similar to those in your patch to add this feature. The rules are always added and just print a message that they are not implemented if a given platform does not provide the rule variables. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest and devenv command line issues
Brad,
Thank you for your reply. I finally had a chance to try it and I must
admit that I only have a partial success to report. The main issue I
have is that I am using a custom command (post build) to generate the
list of test cases used by CTest. So, what happens is that within the
IDE/devenv, I need to have the paths set for my Dlls and Python
libraries.
My partial solution so far is to compile using devenv with /useenv and
then use a CTest script for the submission. This seems to work:
@rem Go to the build directory
c:
cd C:\users\anton\dart-build\msvc7.1-dynamic-IDE\build
@rem Set the env. variables.
call cisstvsvars.bat
call cisstvars.bat Release
@rem Clean and build
devenv /useenv /clean Release /project ALL_BUILD
devenv /useenv /build Release /project ALL_BUILD
C:\Program Files\CMake 2.4\bin\ctest.exe -C Release -S script.cmake
This solution is only partial because ctest will not handle the
compilation and therefore will not report any compiler error to Dart.
Without the ctest script I could not submit. With it I can now submit
but I still can't compile, i.e. it looks like the PATH I set using
SET(CTEST_ENVIRONMENT ...) is not passed properly to devenv ... Any
thoughts?
Anton
On Tue, 2006-07-25 at 16:00 -0400, Brad King wrote:
Anton Deguet wrote:
Hello,
I am trying to setup a couple of nightly builds on a single Windows box.
Since the build requires DLLs (to test our __declspec and Python
wrappers), I have been trying to use the MSVC devenv command line
with /useenv to set the DLL and Python search paths per build. I have
something almost working but I am stuck whenever I try to submit to
Dart. Here is what works (in a small batch script):
@rem Go to the build directory
c:
cd C:\users\anton\dart-build\msvc7.1-dynamic-IDE\build
@rem Set the env. variables.
call cisstvsvars.bat
call cisstvars.bat Release
@rem Clean and build
devenv /useenv /clean Release /project ALL_BUILD
devenv /useenv /build Release /project ALL_BUILD
devenv /useenv /build Release /project RUN_TESTS
At that point, my test programs can find the DLLs and run successfully
but, as expected, nothing gets submitted to my Dart2 dashboard.
The following two won't work:
devenv /useenv /build Release /project Nightly
C:\Program Files\CMake 2.4\bin\ctest.exe -C Release -D Nightly
The error message is that the DLLs are not found. I looks like at one
point my environment variables have been dropped.
Any clue? I am using CMake 2.4.2.
This doesn't work because building the Nightly target just runs another
ctest that constructs its own devenv command line to drive the build and
doesn't add the /useenv option.
CTest is designed to drive dashboard submissions using ctest -S
scripts. See here for an example:
http://www.cmake.org/Testing/Sites/dash4.kitware/Win32-bcc5.8/20060725-1514-Experimental/Notes.html
You can set environment variables in the script:
SET(ENV{VAR1} value1)
SET(ENV{VAR2} value2)
-Brad
--
Anton Deguet [EMAIL PROTECTED]
ERC CISST Johns Hopkins University
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest and devenv command line issues
At 06:25 PM 8/8/2006, Anton Deguet wrote: Brad, Thank you for your reply. I finally had a chance to try it and I must admit that I only have a partial success to report. The main issue I have is that I am using a custom command (post build) to generate the list of test cases used by CTest. So, what happens is that within the IDE/devenv, I need to have the paths set for my Dlls and Python libraries. My partial solution so far is to compile using devenv with /useenv and then use a CTest script for the submission. This seems to work: @rem Go to the build directory c: cd C:\users\anton\dart-build\msvc7.1-dynamic-IDE\build @rem Set the env. variables. call cisstvsvars.bat call cisstvars.bat Release @rem Clean and build devenv /useenv /clean Release /project ALL_BUILD devenv /useenv /build Release /project ALL_BUILD C:\Program Files\CMake 2.4\bin\ctest.exe -C Release -S script.cmake This solution is only partial because ctest will not handle the compilation and therefore will not report any compiler error to Dart. Without the ctest script I could not submit. With it I can now submit but I still can't compile, i.e. it looks like the PATH I set using SET(CTEST_ENVIRONMENT ...) is not passed properly to devenv ... Any thoughts? Anton You might want to look into ctest --build-and-test. We use it in cmake, given a directory with a cmakelist file, it will run cmake on it, then compile it, then run something. You could run that as the first test that creates your other tests maybe -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
