[CMake] Post Build Custom Copy Command
Hi All,
I am using a custom post build command.
ADD_CUSTOM_COMMAND(
TARGET mylib
POST_BUILD
COMMAND copy ARGS ${MYLIBRARY_SOURCE_DIR}/lib/release/mylib.dll
${MYLIBRARY_SOURCE_DIR}/bin/release
COMMAND copy ARGS ${MYLIBRARY_SOURCE_DIR}/lib/release/mylib.lib
${MYLIBRARY_SOURCE_DIR}/lib
)
Since copy does not accept file names of the form
D:/SomeFolder/SomOtherFolder/ and only of the form
D:\SomeFolder\SomOtherFolder\,
the copy command is failing. How can I make this post build command work?
Regards,
Prashanth
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Post Build Custom Copy Command
Prashanth Udupa wrote:
Since copy does not accept file names of the form
D:/SomeFolder/SomOtherFolder/ and only of the form
D:\SomeFolder\SomOtherFolder\,
the copy command is failing. How can I make this post build command
work?
Use
COMMAND ${CMAKE_COMMAND} -E copy
${MYLIBRARY_SOURCE_DIR}/lib/release/mylib.dll
${MYLIBRARY_SOURCE_DIR}/bin/release
-Torsten
This e-mail and any files sent with it contain information that may be
privileged or confidential and is the property of the GateHouse Group. This
information is intended solely for the person to whom it is addressed. If you
are not the intended recipient, you are not authorized to read, print, retain,
copy, disseminate, distribute, or use the message or any part thereof. If you
have received this e-mail in error, please notify the sender immediately, and
delete all copies of this message. In accordance with GateHouse Security
Policy, e-mails sent or received may be monitored.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Post Build Custom Copy Command
Hi,
COMMAND ${CMAKE_COMMAND} -E copy
Thanks. This worked.
Best Regards,
Prashanth
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Get Windows Registry Key!!!! Doesn't work!!!
Berardino la Torre wrote: I'm trying to read an installation path from the windows registry: SET(FBXSDK_ROOT_PATH [HKEY_LOCAL_MACHINE\\SOFTWARE\\FBX\\File SDK 2006.11.1;Install_Dir] CACHE PATH FBX) Where did you see documented that this is supposed to work? -Torsten This e-mail and any files sent with it contain information that may be privileged or confidential and is the property of the GateHouse Group. This information is intended solely for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use the message or any part thereof. If you have received this e-mail in error, please notify the sender immediately, and delete all copies of this message. In accordance with GateHouse Security Policy, e-mails sent or received may be monitored. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get Windows Registry Key!!!! Doesn't work!!!
Quoting Berardino la Torre [EMAIL PROTECTED]:
The problem is you are not capturing the value at all.
For instance, this works:
GET_FILENAME_COMPONENT( CACHE_ROOTDIR
[HKEY_LOCAL_MACHINE\\Software\\InterSystems\\Cache\\Configurations\\CACHE\\Directory;] ABSOLUTE
)
In your case, you'd need to do something like this:
GET_FILENAME_COMPONENT(FBXSDK_ROOT_PATH
[HKEY_LOCAL_MACHINE\\SOFTWARE\\FBX\\File SDK
2006.11.1;Install_Dir] ABSOLUTE CACHE)
Hi All,
I'm trying to read an installation path from the windows registry:
SET(FBXSDK_ROOT_PATH [HKEY_LOCAL_MACHINE\\SOFTWARE\\FBX\\File SDK
2006.11.1;Install_Dir] CACHE PATH FBX) and setup then the include
and lib directories like :
INCLUDE_DIRECTORIES(${FBXSDK_ROOT_PATH}/include)LINK_DIRECTORIES(${FBXSDK_ROOT_PATH}/lib) But nothing seems to happen. The variable FBXSDK_ROOT_PATH got just the value :[HKEY_LOCAL_MACHINE\\SOFTWARE\\FBX\\File SDK 2006.11.1;Install_Dir] like a simple string. I tried also using the syntax (using .. ): SET(FBXSDK_ROOT_PATH [HKEY_LOCAL_MACHINE\\SOFTWARE\\FBX\\File SDK 2006.11.1;Install_Dir]CACHE PATH FBX) but nothing has
changed.
What's wrong with it ?
Ps :
I had a look in the cmake modules folder and found in FindJNI.cmake :
SET(JAVA_AWT_LIBRARY_DIRECTORIES
[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development
Kit\\1.4;JavaHome]/lib
[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development
Kit\\1.3;JavaHome]/lib $ENV{JAVA_HOME}/jre/lib/i386
$ENV{JAVA_HOME}/jre/lib/amd64 /usr/lib /usr/local/lib
/usr/lib/java/jre/lib/i386 /usr/local/lib/java/jre/lib/i386
/usr/local/share/java/jre/lib/i386
/usr/lib/j2sdk1.4-sun/jre/lib/i386
/usr/lib/j2sdk1.5-sun/jre/lib/i386
/opt/sun-jdk-1.5.0.04/jre/lib/amd64 /usr/lib/java/jre/lib/amd64
/usr/local/lib/java/jre/lib/amd64
/usr/local/share/java/jre/lib/amd64
/usr/lib/j2sdk1.4-sun/jre/lib/amd64
/usr/lib/j2sdk1.5-sun/jre/lib/amd64 )
.
I was wondering how it can works
Could anyone explain me in what I'm getting wrong ??? thanks, Bera
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Get Windows Registry Key!!!! Doesn't work!!!
Hi All,
I'm trying to read an installation path from the windows registry:
SET(FBXSDK_ROOT_PATH [HKEY_LOCAL_MACHINE\\SOFTWARE\\FBX\\File SDK
2006.11.1;Install_Dir] CACHE PATH FBX) and setup then the include and lib
directories like :
INCLUDE_DIRECTORIES(${FBXSDK_ROOT_PATH}/include)LINK_DIRECTORIES(${FBXSDK_ROOT_PATH}/lib)
But nothing seems to happen. The variable FBXSDK_ROOT_PATH got just the value
:[HKEY_LOCAL_MACHINE\\SOFTWARE\\FBX\\File SDK 2006.11.1;Install_Dir] like a
simple string. I tried also using the syntax (using .. ):
SET(FBXSDK_ROOT_PATH [HKEY_LOCAL_MACHINE\\SOFTWARE\\FBX\\File SDK
2006.11.1;Install_Dir]CACHE PATH FBX) but nothing has changed.
What's wrong with it ?
Ps :
I had a look in the cmake modules folder and found in FindJNI.cmake :
SET(JAVA_AWT_LIBRARY_DIRECTORIES
[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development
Kit\\1.4;JavaHome]/lib [HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java
Development Kit\\1.3;JavaHome]/lib $ENV{JAVA_HOME}/jre/lib/i386
$ENV{JAVA_HOME}/jre/lib/amd64 /usr/lib /usr/local/lib
/usr/lib/java/jre/lib/i386 /usr/local/lib/java/jre/lib/i386
/usr/local/share/java/jre/lib/i386 /usr/lib/j2sdk1.4-sun/jre/lib/i386
/usr/lib/j2sdk1.5-sun/jre/lib/i386 /opt/sun-jdk-1.5.0.04/jre/lib/amd64
/usr/lib/java/jre/lib/amd64 /usr/local/lib/java/jre/lib/amd64
/usr/local/share/java/jre/lib/amd64 /usr/lib/j2sdk1.4-sun/jre/lib/amd64
/usr/lib/j2sdk1.5-sun/jre/lib/amd64 )
.
I was wondering how it can works
Could anyone explain me in what I'm getting wrong ??? thanks, Bera
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
Instead of adding a new series of option to the cmake tool, why not adding a convenient script generated based on the content of CMakeLists files that is called configure and follow the autoconf way of things. This can be a macro which is used when CPack is used or something like that. On 8/9/07, Brandon Van Every [EMAIL PROTECTED] wrote: On 8/8/07, Philip Lowman [EMAIL PROTECTED] wrote: I don't know where -DUSE_FOO or -D USE_FOO came from, it doesn't appear to be legal in 2.4.6. Oops. Guess I haven't done enough of these to remember how I did them. The fact that people don't even know the proper way to define variables at the command line (myself included) should be proof positive that CMake could use some improvement when operating in command line mode. I don't think that follows. The format for -D is actually well documented in cmake.html. Just because people don't do this a lot with CMake, and don't know things off the top of their heads, doesn't mean the method is wrong, broken, or needing improvement. I think this is purely a marketing issue. Anyways, people can feel free to put a feature request in the bug tracker. I don't see any tremendous harm in allowing --enable-* style commands. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fortran support bugs?
Hello, I would like to use CMake as a build system for a Fortran project of my research group. The problems I'm experiencing are quite various, but I think I've tracked them down to a single cause. In the specific case, which I'm attaching as a compressed archive, CMake runs fine, but when launching make it hangs at the dependency scanning phase. With other Fortran projects, CMake detects bogus dependencies, which do not exist and have strange names. These strange names helped me to identify the probable cause of the bug, since such names are taken from comments in the source code: they consist of portion of phrases, name, adjectives, etc. I think CMake is confused when it finds the USE keyword somewhere in Fortran comments, and it is tricked into thinking that the keyword is specifying some dependency even if it is placed inside a comment. Indeed, by erasing all comments in source files, usually the build is performed successfully. Does this make any sense? I would really like to use CMake for these Fortran projects, since I'm already using it heavily in my C/C++ projects and I love it. Thanks and best regards, Francesco. attitude.tar.bz2 Description: application/tbz ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fortran support bugs?: CMake dependency scanner
I have a added a short FAQ: http://www.cmake.org/Wiki/CMake_FAQ#CMake_dependency_scanner HTH -Mathieu On 8/9/07, yardbird [EMAIL PROTECTED] wrote: Hello, I would like to use CMake as a build system for a Fortran project of my research group. The problems I'm experiencing are quite various, but I think I've tracked them down to a single cause. In the specific case, which I'm attaching as a compressed archive, CMake runs fine, but when launching make it hangs at the dependency scanning phase. With other Fortran projects, CMake detects bogus dependencies, which do not exist and have strange names. These strange names helped me to identify the probable cause of the bug, since such names are taken from comments in the source code: they consist of portion of phrases, name, adjectives, etc. I think CMake is confused when it finds the USE keyword somewhere in Fortran comments, and it is tricked into thinking that the keyword is specifying some dependency even if it is placed inside a comment. Indeed, by erasing all comments in source files, usually the build is performed successfully. Does this make any sense? I would really like to use CMake for these Fortran projects, since I'm already using it heavily in my C/C++ projects and I love it. Thanks and best regards, Francesco. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: cmake ignores .s files
On Thursday 09 August 2007 02:50, felix winkelmann wrote: On 8/8/07, Bill Hoffman [EMAIL PROTECTED] wrote: If gcc would be fine, I think you can do this: set_source_file_properties(foo.s PROPERTIES LANGUAGE C) Still doesn't work: ADD_LIBRARY(... xyz.s) simple ignores the file. (Is this a bug, or intentional - I mean not signalling an error or something ?) I guess it's ignored since its extension doesn't belong to C or C++. So you could: -create a C file which just includes this s file or -use cmake cvs and use the assembler support Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake --help-property EchoString
EchoString is written with lower case characters and is not properly parsed for documentation: $ ./bin/cmake --help-property EchoString cmake version 2.5-20070809 Argument ECHOSTRING to --help-property is not a CMake property. Use --help-property-list to see all properties. Doc also contains a typo: Index: Source/cmTarget.cxx === RCS file: /cvsroot/CMake/CMake/Source/cmTarget.cxx,v retrieving revision 1.161 diff -u -r1.161 cmTarget.cxx --- Source/cmTarget.cxx 3 Aug 2007 20:31:08 - 1.161 +++ Source/cmTarget.cxx 9 Aug 2007 12:30:25 - @@ -91,7 +91,7 @@ cm-DefineProperty (EchoString, cmProperty::TARGET, A message to be displayed when the target is built., - A message to display on some generaters (such as makefiles) when + A message to display on some generators (such as makefiles) when the target is built.); cm-DefineProperty -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake --help-property EchoString
On Thursday 09 August 2007 08:34, Mathieu Malaterre wrote: EchoString is written with lower case characters and is not properly parsed for documentation: $ ./bin/cmake --help-property EchoString cmake version 2.5-20070809 Argument ECHOSTRING to --help-property is not a CMake property. Use --help-property-list to see all properties. Doc also contains a typo: Fixed Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Why prefer ADD_SUBDIRECTORY to SUBDIRS ?
The online help says that we should use ADD_SUBDIRECTORY rather than SUBDIRS, but that SUBDIRS still works. Does anyone know why we're supposed to prefer ADD_SUBDIRECTORY? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fortran support bugs?
yardbird wrote: Hello, I would like to use CMake as a build system for a Fortran project of my research group. The problems I'm experiencing are quite various, but I think I've tracked them down to a single cause. In the specific case, which I'm attaching as a compressed archive, CMake runs fine, but when launching make it hangs at the dependency scanning phase. With other Fortran projects, CMake detects bogus dependencies, which do not exist and have strange names. These strange names helped me to identify the probable cause of the bug, since such names are taken from comments in the source code: they consist of portion of phrases, name, adjectives, etc. I think CMake is confused when it finds the USE keyword somewhere in Fortran comments, and it is tricked into thinking that the keyword is specifying some dependency even if it is placed inside a comment. Indeed, by erasing all comments in source files, usually the build is performed successfully. Does this make any sense? I would really like to use CMake for these Fortran projects, since I'm already using it heavily in my C/C++ projects and I love it. Thanks and best regards, Francesco. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake If I replace the word use in my comments lines in Fortran by _use I don't get the word.mod.proxy error anymore, so this would go in favor of your explanation. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] dependency checking
I've been trying to find a good explanation of how the /fast target works online? Is there a place where the exact behavior documented? Also my concern is that adding a source file to CMakeLists.txt file triggers a rebuild of all source files? Can this be averted by having cmake discover the source files instead of me specifying them? Is there a better way of preventing rebuilds when I know that my changes don't invalidate the object files I already have compiled? Regards, Juan -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why prefer ADD_SUBDIRECTORY to SUBDIRS ?
I;m sure you'll get a better answer ...but as I recall, ADD_SUBDIRECTORY processes the subdir at the time it is called, whereas SUBDIRS pushes the dirs onto a list which is processed at the end of the current cmakelists file - this is the old behaviour and some vars are initialized 'out of order' -or at least in unexpected order JB The online help says that we should use ADD_SUBDIRECTORY rather than SUBDIRS, but that SUBDIRS still works. Does anyone know why we're supposed to prefer ADD_SUBDIRECTORY? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- John Biddiscombe,email:biddisco @ cscs.ch http://www.cscs.ch/about/BJohn.php CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Fortran support bugs?
gname HATES top-posting so badly! yardbird [EMAIL PROTECTED] writes: Hello Francesco, I working on Fortran support enhancements but I'm not finish it yet. In the specific case, which I'm attaching as a compressed archive, CMake runs fine, but when launching make it hangs at the dependency scanning phase. The current fortran source parser, is an adaption of makedepf90-2.6.6 http://www.helsinki.fi/~eedelman/makedepf90.html written by Erik Edelmann seems to be confused by some statement. I have sources which trigger the same issue. However, the changes in makedepf90-2.8.8, which I adapted lately(changes are not in CVS!), fix this problem. Please be patient, I'm doing my best in the spare time I'm able to spend on cmake. Regards, Maik Beckmann ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
On Thursday 09 August 2007 12:57, Juan Sanchez wrote: I've been trying to find a good explanation of how the /fast target works online? Is there a place where the exact behavior documented? Also my concern is that adding a source file to CMakeLists.txt file triggers a rebuild of all source files? Can this be averted by having No, it doesn't. You really only get rebuilds if they are required (e.g. if a header changes or if some compile flag is changed). Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
I just added a source file to the list of sources in my library and now it is recompiling every source file in that library. I don't feel rebuilding the other source files is necessary and I'd like a way to tell cmake to trust me and that any object files I have are still good. Regards, Juan Alexander Neundorf wrote: On Thursday 09 August 2007 12:57, Juan Sanchez wrote: I've been trying to find a good explanation of how the /fast target works online? Is there a place where the exact behavior documented? Also my concern is that adding a source file to CMakeLists.txt file triggers a rebuild of all source files? Can this be averted by having No, it doesn't. You really only get rebuilds if they are required (e.g. if a header changes or if some compile flag is changed). Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why prefer ADD_SUBDIRECTORY to SUBDIRS ?
Because aside from any technical reason, one day Kitware will work up the chutzpah to officially depreciate legacy commands. If you're writing new code, there's no point in using the old commands. Cheers, Brandon Van Every On 8/9/07, Christian Convey [EMAIL PROTECTED] wrote: The online help says that we should use ADD_SUBDIRECTORY rather than SUBDIRS, but that SUBDIRS still works. Does anyone know why we're supposed to prefer ADD_SUBDIRECTORY? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
Juan Sanchez wrote: I just added a source file to the list of sources in my library and now it is recompiling every source file in that library. I don't feel rebuilding the other source files is necessary and I'd like a way to tell cmake to trust me and that any object files I have are still good. Either that is a bug, or a compiler flag has changed. CMake should only rebuild object files if the source (including headers) for that file changes, or if the flags used to compile that object file changes. make -d can be used to figure out why make is rebuilding the object files. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
Hi Bill,
I ran a test and figured out what is triggering the problem. The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}. By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.
If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.
Is there any way to change this behavior? Unfortunately the project I
am porting has source files for multiple libraries in the same
directory. I'd hate to have to list each file individually.
Regards,
Juan
PROJECT(main)
SET (SRCS a.cc b.cc c.cc d.cc e.cc f.cc g.cc)
ADD_EXECUTABLE(a ${SRCS})
ADD_LIBRARY(b ${SRCS})
SET_SOURCE_FILES_PROPERTIES (
${SRCS}
COMPILE_FLAGS -Wall
)
Bill Hoffman wrote:
Juan Sanchez wrote:
I just added a source file to the list of sources in my library and now
it is recompiling every source file in that library. I don't feel
rebuilding the other source files is necessary and I'd like a way to
tell cmake to trust me and that any object files I have are still good.
Either that is a bug, or a compiler flag has changed. CMake should
only rebuild object files if
the source (including headers) for that file changes, or if the flags
used to compile that object
file changes.
make -d can be used to figure out why make is rebuilding the object files.
-Bill
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
Juan Sanchez wrote: I just added a source file to the list of sources in my library and now it is recompiling every source file in that library. I don't feel rebuilding the other source files is necessary and I'd like a way to tell cmake to trust me and that any object files I have are still good. What version of CMake are you running? Simply adding a source file to a library is not enough to trigger a rebuild of that library although it will certainly cause the library to relink. Are you sure you didn't change a common header file or something like that at the same time? If you change the preprocessor definitions or include path the Makefile generator will happily recompile all of the code that needs to be recompiled. This does not happen on Visual Studio however due to limitations with Visual Studio. On a related note: There is a way to disable recompilation based on rule dependencies buried in the useful variables section of the CMake wiki. Simply defining the variable CMAKE_SKIP_RULE_DEPENDENCY temporarily in your CMakeLists.txt will cause CMake to stop the rebuilding of source files that need to be rebuilt. It's best to use this only temporarily and only when you really don't want your development interrupted by a rebuild of your entire source tree. You should remove the variable as soon as you have time to recompile. Not doing so could be dangerous as you might think things are working but not realize the addition of a preprocessor definition or modification of the include path causes things to break. -- Philip Lowman Simulation Development Engineer, Modeling and Simulation Technology General Dynamics Land Systems http://www.gdls.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
Juan Sanchez wrote:
Hi Bill,
I ran a test and figured out what is triggering the problem. The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}. By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.
If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.
Is there any way to change this behavior? Unfortunately the project I
am porting has source files for multiple libraries in the same
directory. I'd hate to have to list each file individually.
Regards,
Juan
PROJECT(main)
SET (SRCS a.cc b.cc c.cc d.cc e.cc f.cc g.cc)
ADD_EXECUTABLE(a ${SRCS})
ADD_LIBRARY(b ${SRCS})
SET_SOURCE_FILES_PROPERTIES (
${SRCS}
COMPILE_FLAGS -Wall
)
OK, this is a bug... Please create a bug report www.cmake.org/Bug.
Include your example if you could. The problem is a comment in the
flags.make file for each .o file with custom flags. I see no reason to
put that comment in the file.
So, to get around the problem you have two choices:
1. use CMAKE_CXX_FLAGS instead.
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wall)
That will change all targets in that directory and below.
2. set CMAKE_SKIP_RULE_DEPENDENCY to true.
I would recommend 1, as 2 will cause trouble if you really do change
flags.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
The problem still exists after adding the PROPERTIES keyword.
Thanks,
Juan
Alexander Neundorf wrote:
On Thursday 09 August 2007 13:32, you wrote:
Hi Bill,
I ran a test and figured out what is triggering the problem. The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}. By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.
If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.
...
SET_SOURCE_FILES_PROPERTIES (
${SRCS}
COMPILE_FLAGS -Wall
)
I didn't test, but here the PROPERTIES keyword is missing. Is it just a
copy'n
paste error or does it still happen if you insert it ?
Alex
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
On 8/9/07, Olivier Delannoy [EMAIL PROTECTED] wrote: Instead of adding a new series of option to the cmake tool, why not adding a convenient script generated based on the content of CMakeLists files that is called configure and follow the autoconf way of things. This can be a macro which is used when CPack is used or something like that. Because we shouldn't be training people to type ./configure indefinitely. We should be training them to use CMake, get them to move on from the Autoconf world. A ./configure script that says dude, you have to type CMake blah blah blah to get what you want would make more sense. But, it is inappropriate to grab the configure filename space. There are projects out there in the process of migration, that have both an Autoconf and a CMake build. Chicken Scheme is one of them. http://www.call-with-current-continuation.org They're probably going to drag their feet about moving on for a looong time. They just don't seem to have an incentive to ditch Autoconf, and they aren't doing enough build maintenance to realize the foolishness of maintaining 2 builds. My plan is simply to refuse to do anything with the Autoconf stuff. Maybe it will wither away. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why prefer ADD_SUBDIRECTORY to SUBDIRS ?
Brandon Van Every wrote: Because aside from any technical reason, one day Kitware will work up the chutzpah to officially depreciate legacy commands. If you're writing new code, there's no point in using the old commands. It looks like they've deprecated a number of old commands in the 2.4 documentation. I was surprised to find that SUBDIRS hasn't been deprecated yet. It does contain a strong suggestion to use ADD_SUBDIRECTORY, however. -- Philip Lowman Simulation Development Engineer, Modeling and Simulation Technology General Dynamics Land Systems http://www.gdls.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fortran support bugs?
On 2007-08-09 13:44+0200 yardbird wrote: Hello, I would like to use CMake as a build system for a Fortran project of my research group. [...]I think CMake is confused when it finds the USE keyword somewhere in Fortran comments, and it is tricked into thinking that the keyword is specifying some dependency even if it is placed inside a comment. Indeed, by erasing all comments in source files, usually the build is performed successfully. Does this make any sense? Yes. That is one of the Fortran bugs, but there are more, see reference below. I would really like to use CMake for these Fortran projects, since I'm already using it heavily in my C/C++ projects and I love it. I use CMake for a couple of Fortran projects, but Fortran is not used by the CMake developers so it tends to be only weakly supported. Thus, there are a number of long-standing CMake fortran bugs you have to work around. I summarized those bugs (and the required workarounds) at http://www.cmake.org/pipermail/cmake/2006-November/012052.html. The workarounds are pretty ugly (for example, change all occurrences of use to _use_ in your comment strings), but I do like CMake so I am willing to put up with the Fortran workarounds for now, although it would be great to get these CMake/Fortran bugs fixed instead. Note, to see the full account of these bugs, you will have to create a new bug tracker account, login to the new CMake bug tracker system and explicitly jump to bugs 3109, 3144, or 3984. Which brings up a general question to those in charge of the bug tracking system: As a convenience to users can you make the bug tracker information available in a read-only way which does not involve logging in? I am well aware you have had to recently fight off a spam attack, but if Mantis is truly a secure system, it should be able to supply read-only information about bugs without requiring an account, logging in, etc. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] -DCMAKE_C_COMPILER:string=g++
Brandon Van Every wrote: On 8/8/07, Alan W. Irwin [EMAIL PROTECTED] wrote: On 2007-08-08 21:52-0400 Bill Hoffman wrote: one of the c files includes a c++ file that is why I need to compile my c files with g++ and not gcc. One of the solution would be to rename my c file cpp or cxx thanks, Marie You can also set the language for that .c file to CXX. set_source_file_properties(foo.c PROPERTIES LANGUAGE CXX) Bill, the LANGUAGE property for set_source_files_properties is not documented. Please fix! I filed bug #5393 a little over 2 weeks ago. We first raised this issue on the mailing list 6 weeks before that. Asking to have it fixed doesn't do any good. I've filed lots of Content bugs over the past year, now called text bugs. Some are trivial to fix, others would take elbow grease to deal with. Almost none have been dealt with. We need a better way for the community to handle this, because Kitware isn't going to deal with most of them. We've had threads about documentation infrastructure in the past 2 months. People have floated some ideas but nobody, including myself, has stepped up to the plate. I've raised the priority on this bug to high because it keeps coming up over and over again. To fix this I have to move the fix onto the branch. The web pages for the online-docs are automatically generated from the branch. I will get to it. But, when something is fixed in CVS, I sort of consider it fixed. This particular problem has come up several times, and I will address it soon -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] -DCMAKE_C_COMPILER:string=g++
On Thursday 09 August 2007 14:14, Brandon Van Every wrote: On 8/8/07, Alan W. Irwin [EMAIL PROTECTED] wrote: On 2007-08-08 21:52-0400 Bill Hoffman wrote: one of the c files includes a c++ file that is why I need to compile my c files with g++ and not gcc. One of the solution would be to rename my c file cpp or cxx thanks, Marie You can also set the language for that .c file to CXX. set_source_file_properties(foo.c PROPERTIES LANGUAGE CXX) Bill, the LANGUAGE property for set_source_files_properties is not documented. Please fix! I filed bug #5393 a little over 2 weeks ago. We first raised this issue on the mailing list 6 weeks before that. Asking to have it fixed doesn't do any good. I've filed lots of Content bugs over the past year, now called text bugs. Some are trivial to fix, others would take elbow grease to deal with. Almost none have been dealt with. We need a better way for the community to handle this, because Kitware isn't going to deal with most of them. That's not completely true, some issues were fixed but simply the bugs were not closed. If you have an improvement for the documentation, it also helps if you create a patch. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
Alexander Neundorf wrote: On Thursday 09 August 2007 13:52, Brandon Van Every wrote: On 8/9/07, Olivier Delannoy [EMAIL PROTECTED] wrote: Instead of adding a new series of option to the cmake tool, why not adding a convenient script generated based on the content of CMakeLists files that is called configure and follow the autoconf way of things. This can be a macro which is used when CPack is used or something like that. Because we shouldn't be training people to type ./configure indefinitely. We should be training them to use CMake, get them to move on from the Autoconf world. A ./configure script that says dude, you have to type CMake blah blah blah to get what you want would make more sense. Yes. Alex We have talked about this in the past, and it would be neat if there was some way to add command line arguments to cmake from the CMakeLists.txt files. However, it is some what tricky to do, and low on the priority list -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
On Thursday 09 August 2007 13:32, you wrote:
Hi Bill,
I ran a test and figured out what is triggering the problem. The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}. By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.
If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.
...
SET_SOURCE_FILES_PROPERTIES (
${SRCS}
COMPILE_FLAGS -Wall
)
I didn't test, but here the PROPERTIES keyword is missing. Is it just a copy'n
paste error or does it still happen if you insert it ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] -DCMAKE_C_COMPILER:string=g++
On 8/9/07, Bill Hoffman [EMAIL PROTECTED] wrote: But, when something is fixed in CVS, I sort of consider it fixed. Closing the bugs in the bug tracker when they get fixed might help communication. For instance, I just closed #3776 CMake -E mkdir. Kudos to whomever fixed it, but the bug was not closed. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] -DCMAKE_C_COMPILER:string=g++
On 8/9/07, Alexander Neundorf [EMAIL PROTECTED] wrote: On Thursday 09 August 2007 14:14, Brandon Van Every wrote: On 8/8/07, Alan W. Irwin [EMAIL PROTECTED] wrote: On 2007-08-08 21:52-0400 Bill Hoffman wrote: one of the c files includes a c++ file that is why I need to compile my c files with g++ and not gcc. One of the solution would be to rename my c file cpp or cxx thanks, Marie You can also set the language for that .c file to CXX. set_source_file_properties(foo.c PROPERTIES LANGUAGE CXX) Bill, the LANGUAGE property for set_source_files_properties is not documented. Please fix! I filed bug #5393 a little over 2 weeks ago. We first raised this issue on the mailing list 6 weeks before that. Asking to have it fixed doesn't do any good. I've filed lots of Content bugs over the past year, now called text bugs. Some are trivial to fix, others would take elbow grease to deal with. Almost none have been dealt with. We need a better way for the community to handle this, because Kitware isn't going to deal with most of them. That's not completely true, some issues were fixed but simply the bugs were not closed. I'll go back over the CVS version of cmake.html later today and see what text bugs are still there. If you have an improvement for the documentation, it also helps if you create a patch. I will try that for the trivial text bugs. The elbow grease text bugs need more infrastructure than that. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Post Build Custom Copy Command
On 8/9/07, Prashanth Udupa [EMAIL PROTECTED] wrote:
Hi All,
I am using a custom post build command.
ADD_CUSTOM_COMMAND(
TARGET mylib
POST_BUILD
COMMAND copy ARGS
${MYLIBRARY_SOURCE_DIR}/lib/release/mylib.dll
${MYLIBRARY_SOURCE_DIR}/bin/release
COMMAND copy ARGS
${MYLIBRARY_SOURCE_DIR}/lib/release/mylib.lib
${MYLIBRARY_SOURCE_DIR}/lib
)
Since copy does not accept file names of the form
D:/SomeFolder/SomOtherFolder/ and only of the form
D:\SomeFolder\SomOtherFolder\,
the copy command is failing. How can I make this post build command work?
As per the docs, FILE(TO_NATIVE_PATH path result) can help with that
sort of thing. Granted, you'd have to read the docs many many times
before knowing details like that.
${CMAKE_COMMAND} -E copy
is also useful.
Finally, you don't need ARGS statements. That's old style.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] -DCMAKE_C_COMPILER:string=g++
On 2007-08-09 14:28-0400 Bill Hoffman wrote: To fix this (documentation bugs fixed in cvs HEAD but not in CVS branch) I have to move the fix onto the branch. The web pages for the online-docs are automatically generated from the branch. I will get to it. But, when something is fixed in CVS, I sort of consider it fixed. This particular problem has come up several times, and I will address it soon I am glad you are going to revamp how you treat documentation fixes. For my own software projects I have an informal rule that small no-brainer changes should be done immediately (or at least the first chance I have to get at the computer) without bothering with bug triage. The point here is there is a substantial cost to bug triage. For example, one cost is some people participating in software projects have a tendency to use the bug triage process as an excuse not to actually make a decision. There are additional costs to bug triage as well since somebody has to make all those decisions about bug category, status changes, etc., etc. If the triage cost is higher than the cost of fixing the bug, then in my view the triage process should be bypassed. Thus, from my perspective, putting documentation fixes on the bug tracker is way overkill. Instead, I suggest you designate some CMake developer who is a good detail person to be responsible for watching list traffic for suggested documentation fixes from your users. If the suggested fixes are no-brainers (which most of them are), then all that designated person has to do is spend a few minutes putting the doc fix into CVS HEAD and release branch and state that fix has been made on list. Of course, that person could also watch the bug tracker for documentation suggestions, but as it became known there was always quick response on the list to documentation suggestions, then the bug tracker and the associated decision making process would be clogged less and less with these minor, no-brainer issues. My $0.02 Canadian. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Libraries variable
Hi,
I don't really know how to explain this but, This is what I would like to do
maindir/
CMakeLists.txt
---
SET(PROJECT_LIBRARIES
${GMP_LIBRARIES}
)
---
subdir1/
CMakeLists.txt
---
SET(PROJECT_LIBRARIES
${PROJECT_LIBRARIES}
anotherlib
)
---
subdir2/
CMakeLists.txt
---
SET(SUB2LIB
${PROJECT_LIBRARIES}
${MYOTHERLIB_LIBRARIES}
)
#in here I would like to find the library anotherlib
---
This does not work, but is there another way like a variable that I
could use? I looked at http://www.cmake.org/Wiki/CMake_Useful_Variables
, but could not find one,
Thanks
Marie
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Fortran support bugs?
On Thursday 09 August 2007, Maik Beckmann wrote: gname HATES top-posting so badly! yardbird [EMAIL PROTECTED] writes: Hello Francesco, I working on Fortran support enhancements but I'm not finish it yet. In the specific case, which I'm attaching as a compressed archive, CMake runs fine, but when launching make it hangs at the dependency scanning phase. The current fortran source parser, is an adaption of makedepf90-2.6.6 http://www.helsinki.fi/~eedelman/makedepf90.html written by Erik Edelmann seems to be confused by some statement. I have sources which trigger the same issue. However, the changes in makedepf90-2.8.8, which I adapted lately(changes are not in CVS!), fix this problem. Please be patient, I'm doing my best in the spare time I'm able to spend on cmake. Regards, Maik Beckmann Thanks Maik and others, I guess in the meantime we will temporarily backup to SCons, and go back to CMake as soon as the Fortran bugs get fixed. It's nothing really fancy, hence the transition will be hopefully painless. Thanks all and best regards, Francesco ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Interest in PyQt4 CMake module?
Hello,
I've developed for my own needs a little CMake module that adds some support
for PyQt4.
In the specific the module looks for the pyuic4 and pyrcc4 binaries and
defines two macros that use those binaries to turn Qt4 UI and Resource file
into Python code to be used in PyQt4.
Most likely the module works only on unix (I don't think PyQt4's Win installer
adds the necessary paths), but maybe it can be used as a basis and improved.
The naming and usage of the macros is modelled after FindQt4.cmake's ones.
Best regards,
Francesco.
# Try to find PyQt4 utilities, pyuic4 and pyrcc4:
# PYUIC4BINARY - Location of pyuic4 executable
# PYRCC4BINARY - Location of pyrcc4 executable
# PyQt4_FOUND - PyQt4 utilities found.
# Also provides macro similar to FindQt4.cmake's WRAP_UI and WRAP_RC,
# for the automatic generation of Python code from Qt4's user interface
# ('.ui') and resource ('.qrc') files. These macros are called:
# - PYQT4_WRAP_UI
# - PYQT4_WRAP_RC
IF(PYUIC4BINARY AND PYRCC4BINARY)
# Already in cache, be silent
set(PyQt4_FIND_QUIETLY TRUE)
ENDIF(PYUIC4BINARY AND PYRCC4BINARY)
FIND_PROGRAM(PYUIC4BINARY pyuic4)
FIND_PROGRAM(PYRCC4BINARY pyrcc4)
MACRO(PYQT4_WRAP_UI outfiles)
FOREACH(it ${ARGN})
GET_FILENAME_COMPONENT(outfile ${it} NAME_WE)
GET_FILENAME_COMPONENT(infile ${it} ABSOLUTE)
SET(outfile ${CMAKE_CURRENT_BINARY_DIR}/ui_${outfile}.py)
ADD_CUSTOM_TARGET(${it} ALL
DEPENDS ${outfile}
)
ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
COMMAND ${PYUIC4BINARY} ${infile} -o ${outfile}
MAIN_DEPENDENCY ${infile}
)
SET(${outfiles} ${${outfiles}} ${outfile})
ENDFOREACH(it)
ENDMACRO (PYQT4_WRAP_UI)
MACRO(PYQT4_WRAP_RC outfiles)
FOREACH(it ${ARGN})
GET_FILENAME_COMPONENT(outfile ${it} NAME_WE)
GET_FILENAME_COMPONENT(infile ${it} ABSOLUTE)
SET(outfile ${CMAKE_CURRENT_BINARY_DIR}/${outfile}_rc.py)
ADD_CUSTOM_TARGET(${it} ALL
DEPENDS ${outfile}
)
ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
COMMAND ${PYRCC4BINARY} ${infile} -o ${outfile}
MAIN_DEPENDENCY ${infile}
)
SET(${outfiles} ${${outfiles}} ${outfile})
ENDFOREACH(it)
ENDMACRO (PYQT4_WRAP_RC)
IF(EXISTS ${PYUIC4BINARY} AND EXISTS ${PYRCC4BINARY})
set(PyQt4_FOUND TRUE)
ENDIF(EXISTS ${PYUIC4BINARY} AND EXISTS ${PYRCC4BINARY})
if(PyQt4_FOUND)
if(NOT PyQt4_FIND_QUIETLY)
message(STATUS Found PyQt4: ${PYUIC4BINARY}, ${PYRCC4BINARY})
endif(NOT PyQt4_FIND_QUIETLY)
endif(PyQt4_FOUND)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
Brandon Van Every wrote: On 8/8/07, gga [EMAIL PROTECTED] wrote: I know I can pass -D symbols to cmake to modify its behavior and that windows also has its ugly CmakeSetup gui. Ugly? Geez, what are you, a candidate for Windows Aero or something? No, I am a candidate for something that works and ccmake/cmakesetup does not work well. Don't confuse eye candy with functionality. When I mean ugly, I mean there's basic functionality missing from ccmake/cmakesetup. This, unfortunately, clearly rules cmake from being a good candidate to replace autotools, even if its core is much better. The problems with the current approach are: - Variables for configuration are unknown to the user unless he digs into all of the cmake modules used. Compare this to running any autotools project: ./configure (you get full help for all the libs and options you can use). ./cmake (I get cmake's documentation, nothing about my project) ../ccmake (on a clean project) (Nothing) - ccmake/cmakesetup list variables in the cache only. If you are building out of source (as I do), the CMakeCache.txt and the CMakeLists.txt are in different directories, which again can be confusing to a user. - As ccmake/cmakesetup rely on cached variables, a user running the project for the first time will not get ANY variables when he runs ccmake. He HAS to run cmake first. - ccmake/cmakesetup lists pretty much ALL variables. Scary as hell to a user not familiar with your project and tedious to find the variable you need if you do know the project. - AFAIK, -D does not allow DISABLING options, like --disable-X does. The FindXXX modules will take over and find the library even if I told it to disable some library. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
