Re: [CMake] XCode generator hangs when writing build config.
On 05/01/2012 01:56, David Cole wrote:
Wow. Nice, quick work.
Thanks for the patch. I'll get it applied and pushed to our 'next'
branch so this can get into the next release...
Thanks,
David
Hmmm. I've downloaded the source from SourceForge, but do not
reproduce the problem here simply by running cmake to
configure/generate. You must be setting the flags explicitly somehow?
(By hand, or with a script?)
You may need to checkout from sourceforge CVS, the tar ball is not that
recent.
Can you tell me exactly how to reproduce the problem so that I can
verify the fix works?
You may need to force your compiler to be gcc (clang or llvm)
I don't have the latter so I don't know whether they pass or not.
You see the logic of setting the compiler flags in
EASDIF_SDIF/SDIF/cmModules/SET_COMPILER_FLAGS.cmake
here
...
IF (GCCVERSIONMAJ EQUAL 4)
ADD_BT_COMPILER_FLAGS(RELEASE -finline-limit=5000 --param
large-function-insns=5000 --param large-function-growth=500 --param
inline-unit-growth=100)
So only gcc will trigger the problem
As far as I remember i did not have this machinery when I published the
last tar ball.
Please find attached a minimal example project (source tt.cc and
CMakeLists.txt) that trigger the problem.
Best
Axel
The ExtractFlags method was modified in this commit to remove
conflicting -g flags when multiple -g flags occur...
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cb22afc0
It's relatively recent and first appeared in 2.8.6 -- I want to make
sure that whatever fix goes in now also honors the intent of that
commit, which fixed http://public.kitware.com/Bug/view.php?id=12377
Thanks,
David
--
Axel Roebel
Head of the Analysis/Synthesis Team, IRCAM
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
// string::rfind
#include iostream
#include string
using namespace std;
int main ()
{
string str (The sixth sick sheik's sixth sheep's sick.);
string key (sixth);
size_t found;
found=str.rfind(key);
if (found!=string::npos)
str.replace (found,key.length(),seventh);
cout str endl;
return 0;
}
project(tt )
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} --param large-function-insns=5000
--param large-function-growth=500 --param inline-unit-growth=100)
add_executable(tt tt.cc)--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] trouble with cmake 2.6-patch 0 cross compiling.
On Wednesday 16 July 2008 8:54:11 pm [EMAIL PROTECTED] wrote: Hi. I've got cmake 2.6-patch 0 installed and I'm trying to get a simple (helloworld.cpp) compiled and built on a linux system. My toolchain file looks like this: -- toolchain.cmake -- SET( CMAKE_SYSTEM_NAME foobar ) SET( CMAKE_SYST EM_VERSION 1 ) SET( CMAKE_SYSTEM_PROCESSOR arm-foo ) SET( CMAKE_SYSTEM_C_COMPILER /absolute/path/to/compiler ) SET( CMAKE_SYSTEM_CXX_COMPILER /absolute/path/to/compiler ) Hi Phil, I think you simply mixed these up. The last ones should be SET( CMAKE_C_COMPILER /absolute/path/to/compiler ) SET( CMAKE_CXX_COMPILER /absolute/path/to/compiler ) no SYSTEM_ there! see: http://www.cmake.org/Wiki/CMake_Cross_Compiling Cheers, Axel SET( CMAKE_FIND_ROOT_PATH /absolute/path/to/compiler/tools ) SET( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER ) SET( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY ) SET( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY ) -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] to_cmake_path/to_native_path oddities
Hi, I just switched from 2.4.8 to 2.6 and found a very strange behavior in one of my existing cmake projects. I am trying to find the include files (and libraries) of Intels mkl libraries with the following cmake code FIND_PATH(MKL_INCLUDE_PATH_TMP mkl_dfti.h PATHS /usr/include /usr/local/include /u/formes/share/include /cygdrive/c/Program Files/Intel/MKL/10.0.1.014/include) Now in cmake 2.4.8 this returned /cygdrive/c/Program Files/Intel/MKL/10.0.1.014/include while in cmake 2.6.0 it creates c:\Program Files\Intel\MKL\10.0.1.014\include a path that it found in the environment variable INCLUDE This seems already somewhat buggy tpo me because I would have expected that in a unix makefile generator the variable should be automatically converted to unix path style. Then I thought to use the to_cmake_path/to_native_path facilities to convert the path to unix flavor. (BTW I am not quite sure what native means in cygwin compiled cmake on windows). Neither of these two did anything useful though. Both ended up with something like c /Program Files/Intel/MKL/10.0.1.014/include which after looking in the source code is obviously due to the fact that the fist thing both TO_*_PATH commands do is #if defined(_WIN32) !defined(__CYGWIN__) char pathSep = ';'; #else char pathSep = ':'; #endif std::vectorcmsys::String path = cmSystemTools::SplitString(i-c_str(), pathSep); this means for CYGWIN it will always use : as path separator splitting the c from the rest and then converting to unix style path. So in short the path conversion for cygwin is working only in one (completely useless) case: unix style path - unix style path While I submitted this as a bug report I wonder if there are any workarounds that I might use to get the unix style path with the current cmake 2.6.0 Kind regards, -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] to_cmake_path/to_native_path oddities
On Wednesday 28 May 2008, Bill Hoffman wrote:
Axel Roebel wrote:
Hi,
I just switched from 2.4.8 to 2.6 and found a very strange behavior in
one of my existing cmake projects. I am trying to find the include files
(and libraries) of Intels mkl libraries with the following cmake code
FIND_PATH(MKL_INCLUDE_PATH_TMP mkl_dfti.h PATHS /usr/include
/usr/local/include /u/formes/share/include /cygdrive/c/Program
Files/Intel/MKL/10.0.1.014/include)
Now in cmake 2.4.8 this returned
/cygdrive/c/Program Files/Intel/MKL/10.0.1.014/include
while in cmake 2.6.0 it creates
c:\Program Files\Intel\MKL\10.0.1.014\include
a path that it found in the environment variable INCLUDE
Thanks Bill,
So, we added more places to look for things (INCLUDE).
I see, that explains at least why it does not work anymore.
You may want to
try the Unix Makefile generator and the windows binary of cmake. The
cygwin cmake really does not work very will with native windows
programs. It really is meant to work in the cygwin environment with the
cygwin tool chain. You could add NO_DEFAULT_PATH to your FIND_PATH call
and it would stop cmake from looking in INCLUDE.
Unix makefile generator with windows binary was our first trial. How can I set
the compiler to use ? icl is not the standard compiler for unix makefiles?
Anyway, I doubt that windows cmake will convert pathes to unix style before
writing it into the unix makefile. As far as I saw it didn't.
Yes NO_DEFAULT_PATH is probably the best fix to this problem. I tried that
already.
This seems already somewhat buggy tpo me because I would have expected
that in a unix makefile generator the variable should be automatically
converted to unix path style.
The path should be converted before it is actually used if you pass it
to say include_directories.
I would like to, but I actually can't in cmake. I think this is a problem
of cmake.
Then I thought to use the to_cmake_path/to_native_path facilities to
convert the path to unix flavor. (BTW I am not quite sure what native
means in cygwin compiled cmake on windows). Neither of these two did
anything useful though. Both ended up with something like
c /Program Files/Intel/MKL/10.0.1.014/include
which after looking in the source code is obviously due to the fact that
the fist thing both TO_*_PATH commands do is
#if defined(_WIN32) !defined(__CYGWIN__)
char pathSep = ';';
#else
char pathSep = ':';
#endif
std::vectorcmsys::String path =
cmSystemTools::SplitString(i-c_str(),pathSep);
this means for CYGWIN it will always use : as path separator splitting
the c from the rest and then converting to unix style path. So in short
the path conversion for cygwin is working only in one (completely
useless) case:
unix style path - unix style path
While I submitted this as a bug report I wonder if there are any
workarounds that I might use to get the unix style path with the current
cmake 2.6.0
We would have to create a new command to do that. If you check the
docs for TO_CMAKE_PATH, it says you can pass in things like:
$ENV{PATH}, so it allows for and was intended to work with paths
separated by the native path separator.Again, cygwin does not play
Could you explain to me what conversion TO_CMAKE_PATH is actually doing if you
supply it $ENV{PATH} in a cygwin environment. It seems to me that it wouild
not do anything because the result is already in unix format.
If however I used $ENV{INCLUDE} it would not work. So from the two possible
situations this command seems to work only for the one that is useless
unix - unix. may be I am missing something here?
It seems to me that a TO_CMAKE_PATH that transforms to unix should assume that
the input path is in windows form (; separators).
nice with windows tools. I mean if you passed -I/cygdrive/c/Program
Files/Intel/MKL/10.0.1.014/include to the intel compiler, it would not
be able to use it would it?
My main platforms are Linux and MacOSX, but I have to support Windows MSVC,
gcc and icl. All my test scripts are unix shell scripts that will be run as
makefile targets (using cygpath to adapt pathes).
So I prefer my environment as unix like as possible.
Accordingly, I wrote an icl redirection shell script replacing all unix paths
by equivalent windows paths.
So -I/cygdrive/c/ProgramFiles/Intel/MKL/10.0.1.014/include
is perfect for me.
I agree this enviroment is not common. I still believe though that the
TO_CMAKE_PATH is
-Bill
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] to_cmake_path/to_native_path oddities
On Wednesday 28 May 2008, Alin M Elena wrote: Hi, This is a little bit out of topic. Are you sure that you need to use cygwin? I have ported few unix projects to native windows just using powershell free microsoft compilers cmake (nmake file generator) optionally you may need unxtools I see that you have MKL I suspect that you have intel compilers, too. Unless you have very strong reasons to use cygwin (some strange third party libs) I would not waste my time with it. Hi Alin, I am developing mainly on linux and MacOSX and I am using Windows only as test environment for all sorts of windows compilers. So I am very happy to be able to use a familiar unix environment. I have a huge test suite written in shell scripts that work very well in CYGWIN. This seems the only environment supported on all three platforms. Axel Alin -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] to_cmake_path/to_native_path oddities
On Wednesday 28 May 2008, Bill Hoffman wrote: Axel Roebel wrote: You may want to try the Unix Makefile generator and the windows binary of cmake. The cygwin cmake really does not work very will with native windows programs. It really is meant to work in the cygwin environment with the cygwin tool chain. You could add NO_DEFAULT_PATH to your FIND_PATH call and it would stop cmake from looking in INCLUDE. Unix makefile generator with windows binary was our first trial. How can I set the compiler to use ? icl is not the standard compiler for unix makefiles? Anyway, I doubt that windows cmake will convert pathes to unix style before writing it into the unix makefile. As far as I saw it didn't. set environment variables CC,CXX, and FC to the compilers you want cmake to use before you run cmake, and it should work. Hi Bill, Ok I see you mean running the windows binary from the command line. However,it does not work with unix makefiles. It uses windows paths in a unix makefile. I don't see in which situation this could be useful. I get rec-1320: (build) 334 make libfft/src/CMakeFiles/fft_static.dir/build.make:53: *** target pattern contains no `%'. Stop. make[1]: *** [libfft/src/CMakeFiles/fft_static.dir/all] Error 2 make: *** [all] Error 2 The makefile is actually invalid. This seems already somewhat buggy tpo me because I would have expected that in a unix makefile generator the variable should be automatically converted to unix path style. The path should be converted before it is actually used if you pass it to say include_directories. I would like to, but I actually can't in cmake. I think this is a problem of cmake. What error do you get? ??? I don't get an error, there is simply no function to convert a windows path into a unix path. I understand I have to make my own macro. Thanks, -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Bugs in cmake-2.4.6, please solve for 2.4.7
On Tuesday 17 July 2007 03:06:15 [EMAIL PROTECTED] wrote: Re: Bugs in cmake-2.4.6, please solve for 2.4.7 Hi all, I would like to draw your attention to bug report 4209 that I submitted last year already: If you want your cmake project to be used with the xcode generator better stay away completely from EXCLUDE_FROM_ALL because the xcode generator will simply exclude all EXCLUDE_FROM_ALL targets completely such that you cannot even build them manually. It seems to me that this is a severe bug that should be fixed as soon as possible because it means you cannot rely on the fact that your cmake projects will work at all with all the supported generators. I work around this since quite a while and I am somewhat astonished to see that this bug seems not to have been adressed in the upcoming release. The same seems to hold true for bug 5238 and 5213 where libraries and executables that have a VERSION set in SET_TARGET_PROPERTIES will result in errors when using unix makefiles on cygwin. Same problem here. This means you have to adapt your cmake projects because otherwise they fail to produce a usuable result with some generators. So in short: if you intend to be portable with the current and the upcoming version of cmake better don't use VERSION and don't use EXCLUDE_FROM_ALL. Kind regards, -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Bugs in cmake-2.4.6, please solve for 2.4.7
On Tuesday 17 July 2007, [EMAIL PROTECTED] wrote: From: Hendrik Sattler [EMAIL PROTECTED] Zitat von Axel Roebel [EMAIL PROTECTED]: So in short: if you intend to be portable with the current and the upcoming version of cmake better don't use VERSION and don't use EXCLUDE_FROM_ALL. So what? Xcode and Cygwin Makefiles generators are broken, that's no reason for me to not use the stuff that works with all others. On MacOS X, you can probably use plain Makefiles instead? Very wise, as long as you use the project yourself you can do that. If you publish your project and you get users complaining about not being able to use what you provided you'll see that it will be you who has to deal with the problems. Not using VERSION property is not a good choice. Some systems that do not know about SONAME (which ones?) may need it to be able to use/install multiple versions of a library at the same time. You got the point. So that's why I considered VERSION to be important to be fixed. PS: if it's not a generator that's broken, then it may as well be the make implementation or a strange concept of an IDE. And if that all works, you'll always hit messy compilers ;) Very helpful this remark as well, thanks a lot. So you suggest not fixing cmake bugs because if they are fixed maybe the makefile or IDE will be broken anyway. Did you think about the main reason cmake came to existence? At least as I understand it and why I use it and what is written on the main cmake page is: platform and compiler portable project generation. The attitude my build tool is important but yours is a mess is certainly what is the least helpful here. -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] PCHSupport.cmake
I uploaded my current version of PCHSupport.cmake as attachment to bug 1260. The cmake module now supports adding the same precompiled header to multiple targets following a proposition by frederic heem See: http://www.cmake.org/Bug/bug.php?op=showbugid=1260pos=1 -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake: INSTALL not working with subdirectories
On Wednesday 17 January 2007 12:18, Otavio Rodolfo Piske wrote: Hi Eric, On 1/17/07, Eric Noulard [EMAIL PROTECTED] wrote: 2007/1/16, Otavio Rodolfo Piske [EMAIL PROTECTED]: Hi, I almost solve the problem! I took a closer look at my top-level CMakeLists.txt and could find it referencing to a directory that it shouldn't. After I commented it, it now installs the files of the last one of the processed modules in the top-level CMakeLists.txt. If you take a look at it (available at http://svn.angusyoung.org/nus/CMakeLists.txt ) you'll notice the last module to be added is MODULE_XML ... so now I have the following output of make install: [..] What I could note in the file cmake_install.cmake is the following comment: # Install script for directory: /home/otavio/projects/nus/./src/xml The directory /home/otavio/projects/nus/./src/xml is where is the CMakeLists.txt file for the XML module. Any ideas? Thanks in advance! Could you explain us why you ADD_SUBDIRECTORY( src/network . ) instead of ADD_SUBDIRECTORY( src/network ) do you really want . (dot) to be the binary_dir for the specified subdir? When I was originally moving from the old build tree to this one, I received a messaged about not having defined a binary_dir (or, at least, something very similar to that). Since you noted that I removed the 'binary_dir' option from ADD_SUBDIRECTORY and everything seems to be fine. I still have to test this on windows, though. I don't know if it is related to your problem but it seems an odd choice to me. Moreover I don't really understand what are your remaining problems? What should be installed and is not? Eric, my problem is that if I do this: ADD_SUBDIRECTORY( src/a ) ADD_SUBDIRECTORY( src/b ) ADD_SUBDIRECTORY( src/c ) only the contents of the directory src/c will be installed. I temporally solved the problem by doing the following : 1) I created a deploy directory with 2 files: - a CMakeLists.txt that will include any module that should be installed. So, each module has a CMakeInstall.txt file that is included by this one. You can see what I'm talking about here: http://svn.angusyoung.org/nus/deploy/CMakeLists.txt - a CMakeInstall.txt with the macros that will install the files: http://svn.angusyoung.org/nus/deploy/CMakeInstall.txt 2) Then, for each module I created a CMakeInstall.txt file that calls the installation macros to install its files. Again, you can see it here: http://svn.angusyoung.org/nus/src/network/CMakeInstall.txt 3) On the top-level CMakeLists.txt file I added the deploy directory to end of the file. So, to make it short: my problem seems to be that CMake overwrites cmake_install.cmake each time it runs ADD_SUBDIRECTORY, so making it generate installation scripts for only the last of the added directories. For many of the projects I have I have exactly the same structure src/a src/b src/c and installing from some or all of these sub-directories using the install command in the CMakeLists.txt of the sub directories does not pose any problem with cmake. If the install from a certain subdirectory is missing (src/xml in your case) I would suggest you carefully check the CMakeLists.txt of that directory. Chances are you made an error there. Cheers, P.S.: sorry I'm not clear enough, english isn't my primary language. Thanks in advance -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting CMAKE_MODULE_PATH removes the default path?
On Thursday 11 January 2007 16:47, Pierre wrote:
Hello,
Doing:
SET(CMAKE_MODULE_PATH ${FOO_CMAKE_DIR})
Effectively this is correct, it worked for me like this
on all cmake versions I ever tried. The default path
should be searched for automagically.
You find the implementation in
cmake-source-dir/Source/cmMakefile.cxx
function GetModulesFiles.
The default location is
${CMAKE_ROOT}/Modules.
You may want to check whether
your CMAKE_ROOT variable
is correct...
removes the default module path (${CMAKE_ROOT}/Modules here on ubuntu
with 2.4.3). It is not possible anymore to call system macros like
check_include_file. Is it the expected behavior?
I thought setting CMAKE_MODULE_PATH adds a path but do not replace the
default one. Is there a way to get back the system path and add it
again (as a workaround)?
Regards,
--Pierre
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] -fPIC and precompiled header
On Saturday 06 January 2007 18:42, you wrote:
Am Freitag, den 05.01.2007, 01:14 +0100 schrieb Axel Roebel:
GET_TARGET_PROPERTY(_targetType ${_PCH_current_target} TYPE)
SET(PHC_MASTER_INCLUDE_FILE ${_input})
CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/cmModules/PCHCheckDependencies.cxx.i
n ${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_gchdep.cxx)
Axel, this forces everyone to use cmModules as the name of the folder
were to save PCHSupport.cmake .
I suggest to use a macro to create the file:
MACRO(_PCH_WRITE_GCHDEP_CXX _targetName _include_file)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_gchdep.cxx
#include \${_include_file}\
int testfunction()
{
return 0;
}
)
ENDMACRO(_PCH_WRITE_GCHDEP_CXX )
and use it like this:
GET_TARGET_PROPERTY(_targetType ${_PCH_current_target} TYPE)
_PCH_WRITE_GCHDEP_CXX(${_targetName} ${_input} )
IF(${_targetType} STREQUAL SHARED_LIBRARY)
ADD_LIBRARY(${_targetName}_gchdep SHARED
${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_gchdep.cxx)
ELSE(${_targetType} STREQUAL SHARED_LIBRARY)
ADD_LIBRARY(${_targetName}_gchdep STATIC
${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_gchdep.cxx)
ENDIF(${_targetType} STREQUAL SHARED_LIBRARY)
This worked for me.
For me as well, so here it is.
BTW: Consider to use pchdep not gchdep, since gch is related to gcc
only.
I changed the names but it seems that the output the directory is always
called gch.
Cheers,
Axel
MfG Maik
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
# - Try to find precompiled headers support for GCC 3.4 and 4.x
# Once done this will define:
#
# Variable:
# PCHSupport_FOUND
#
# Macro:
# ADD_PRECOMPILED_HEADER
IF(CMAKE_COMPILER_IS_GNUCXX)
EXEC_PROGRAM(
${CMAKE_CXX_COMPILER}
ARGS${CMAKE_CXX_COMPILER_ARG1} -dumpversion
OUTPUT_VARIABLE gcc_compiler_version)
MESSAGE(GCC Version: ${gcc_compiler_version})
IF(gcc_compiler_version MATCHES 4\\.[0-9]\\.[0-9])
SET(PCHSupport_FOUND TRUE)
ELSE(gcc_compiler_version MATCHES 4\\.[0-9]\\.[0-9])
IF(gcc_compiler_version MATCHES 3\\.4\\.[0-9])
SET(PCHSupport_FOUND TRUE)
ENDIF(gcc_compiler_version MATCHES 3\\.4\\.[0-9])
ENDIF(gcc_compiler_version MATCHES 4\\.[0-9]\\.[0-9])
SET(_PCH_include_prefix -I)
ELSE(CMAKE_COMPILER_IS_GNUCXX)
IF(WIN32)
SET(PCHSupport_FOUND TRUE) # for experimental msvc support
SET(_PCH_include_prefix /I)
ELSE(WIN32)
SET(PCHSupport_FOUND FALSE)
ENDIF(WIN32)
ENDIF(CMAKE_COMPILER_IS_GNUCXX)
MACRO(_PCH_GET_COMPILE_FLAGS _out_compile_flags)
STRING(TOUPPER CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE} _flags_var_name)
SET(${_out_compile_flags} ${${_flags_var_name}} )
IF(CMAKE_COMPILER_IS_GNUCXX)
GET_TARGET_PROPERTY(_targetType ${_PCH_current_target} TYPE)
IF(${_targetType} STREQUAL SHARED_LIBRARY)
LIST(APPEND ${_out_compile_flags} ${${_out_compile_flags}} -fPIC)
ENDIF(${_targetType} STREQUAL SHARED_LIBRARY)
ELSE(CMAKE_COMPILER_IS_GNUCXX)
## TODO ... ? or does it work out of the box
ENDIF(CMAKE_COMPILER_IS_GNUCXX)
GET_DIRECTORY_PROPERTY(DIRINC INCLUDE_DIRECTORIES )
FOREACH(item ${DIRINC})
LIST(APPEND ${_out_compile_flags} ${_PCH_include_prefix}${item})
ENDFOREACH(item)
GET_DIRECTORY_PROPERTY(_directory_flags DEFINITIONS)
#MESSAGE(_directory_flags ${_directory_flags} )
LIST(APPEND ${_out_compile_flags} ${_directory_flags})
LIST(APPEND ${_out_compile_flags} ${CMAKE_CXX_FLAGS} )
SEPARATE_ARGUMENTS(${_out_compile_flags})
ENDMACRO(_PCH_GET_COMPILE_FLAGS)
MACRO(_PCH_WRITE_PCHDEP_CXX _targetName _include_file)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_pchdep.cxx
#include \${_include_file}\
int testfunction()
{
return 0;
}
)
ENDMACRO(_PCH_WRITE_PCHDEP_CXX )
MACRO(_PCH_GET_COMPILE_COMMAND out_command _input _output)
FILE(TO_NATIVE_PATH ${_input} _native_input)
FILE(TO_NATIVE_PATH ${_output} _native_output)
IF(CMAKE_COMPILER_IS_GNUCXX)
IF(CMAKE_CXX_COMPILER_ARG1)
# remove leading space in compiler argument
STRING(REGEX REPLACE ^ + pchsupport_compiler_cxx_arg1
${CMAKE_CXX_COMPILER_ARG1})
SET(${out_command}
${CMAKE_CXX_COMPILER} ${pchsupport_compiler_cxx_arg1}
${_compile_FLAGS} -x c++-header -o ${_output} ${_input}
)
ELSE(CMAKE_CXX_COMPILER_ARG1)
SET(${out_command}
${CMAKE_CXX_COMPILER} ${_compile_FLAGS} -x c++-header -o
${_output} ${_input}
)
ENDIF(CMAKE_CXX_COMPILER_ARG1)
ELSE(CMAKE_COMPILER_IS_GNUCXX)
SET(_dummy_str #include ${_input})
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/pch_dummy.cpp
${_dummy_str})
SET(${out_command
Re: [CMake] -fPIC and precompiled header
On Saturday 06 January 2007 16:05, Axel Roebel wrote:
On Saturday 06 January 2007 11:29, you wrote:
I will merge your changes today. Many thanks!
NOTE:
Consider that I'm not a maintainer. I'm just a developer who was annoyed
by the long compile times when using boost. Feel encouraged to make
changes to fulfill your needs and keep on posting the resulting
cmake-file. I will do my very best to merge your and others
modifications into one cmake file.
Don't bother I have these changes, I'll post them
soon. The last thing I'd like to add is correct handling
of distcc which is currently not working with
your version of PCHSupport.cmake.
Cheers,
Hi Maik,
Find attached my modified version.
The changes applied are all the comments from my previous mail
(the compiler test is still sub optimal but as I am not using windows...)
Moreover I simplified the compiler version determination
and fixed PCHSupport.cmake such that you can use it with
distcc as in
CC=distcc /usr/local/bin/gcc CXX=distcc /usr/local/bin/gcc cmake ..
BTW, if you have more then one computer available and you suffer from
long compilation times distcc is really worth it! I distribute
compilation even over internet to my company and I still get
compile time reduction of 25%.
I hope these changes work for you as well.
Bis demnaechst,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
# - Try to find precompiled headers support for GCC 3.4 and 4.x
# Once done this will define:
#
# Variable:
# PCHSupport_FOUND
#
# Macro:
# ADD_PRECOMPILED_HEADER
IF(CMAKE_COMPILER_IS_GNUCXX)
EXEC_PROGRAM(
${CMAKE_CXX_COMPILER}
ARGS${CMAKE_CXX_COMPILER_ARG1} -dumpversion
OUTPUT_VARIABLE gcc_compiler_version)
MESSAGE(GCC Version: ${gcc_compiler_version})
IF(gcc_compiler_version MATCHES 4\\.[0-9]\\.[0-9])
SET(PCHSupport_FOUND TRUE)
ELSE(gcc_compiler_version MATCHES 4\\.[0-9]\\.[0-9])
IF(gcc_compiler_version MATCHES 3\\.4\\.[0-9])
SET(PCHSupport_FOUND TRUE)
ENDIF(gcc_compiler_version MATCHES 3\\.4\\.[0-9])
ENDIF(gcc_compiler_version MATCHES 4\\.[0-9]\\.[0-9])
SET(_PCH_include_prefix -I)
ELSE(CMAKE_COMPILER_IS_GNUCXX)
IF(WIN32)
SET(PCHSupport_FOUND TRUE) # for experimental msvc support
SET(_PCH_include_prefix /I)
ELSE(WIN32)
SET(PCHSupport_FOUND FALSE)
ENDIF(WIN32)
ENDIF(CMAKE_COMPILER_IS_GNUCXX)
MACRO(_PCH_GET_COMPILE_FLAGS _out_compile_flags)
STRING(TOUPPER CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE} _flags_var_name)
SET(${_out_compile_flags} ${${_flags_var_name}} )
IF(CMAKE_COMPILER_IS_GNUCXX)
GET_TARGET_PROPERTY(_targetType ${_PCH_current_target} TYPE)
IF(${_targetType} STREQUAL SHARED_LIBRARY)
LIST(APPEND ${_out_compile_flags} ${${_out_compile_flags}} -fPIC)
ENDIF(${_targetType} STREQUAL SHARED_LIBRARY)
ELSE(CMAKE_COMPILER_IS_GNUCXX)
## TODO ... ? or does it work out of the box
ENDIF(CMAKE_COMPILER_IS_GNUCXX)
GET_DIRECTORY_PROPERTY(DIRINC INCLUDE_DIRECTORIES )
FOREACH(item ${DIRINC})
LIST(APPEND ${_out_compile_flags} ${_PCH_include_prefix}${item})
ENDFOREACH(item)
GET_DIRECTORY_PROPERTY(_directory_flags DEFINITIONS)
#MESSAGE(_directory_flags ${_directory_flags} )
LIST(APPEND ${_out_compile_flags} ${_directory_flags})
LIST(APPEND ${_out_compile_flags} ${CMAKE_CXX_FLAGS} )
SEPARATE_ARGUMENTS(${_out_compile_flags})
ENDMACRO(_PCH_GET_COMPILE_FLAGS)
MACRO(_PCH_GET_COMPILE_COMMAND out_command _input _output)
FILE(TO_NATIVE_PATH ${_input} _native_input)
FILE(TO_NATIVE_PATH ${_output} _native_output)
IF(CMAKE_COMPILER_IS_GNUCXX)
IF(CMAKE_CXX_COMPILER_ARG1)
# remove leading space in compiler argument
STRING(REGEX REPLACE ^ + pchsupport_compiler_cxx_arg1
${CMAKE_CXX_COMPILER_ARG1})
SET(${out_command}
${CMAKE_CXX_COMPILER} ${pchsupport_compiler_cxx_arg1}
${_compile_FLAGS} -x c++-header -o ${_output} ${_input}
)
ELSE(CMAKE_CXX_COMPILER_ARG1)
SET(${out_command}
${CMAKE_CXX_COMPILER} ${_compile_FLAGS} -x c++-header -o
${_output} ${_input}
)
ENDIF(CMAKE_CXX_COMPILER_ARG1)
ELSE(CMAKE_COMPILER_IS_GNUCXX)
SET(_dummy_str #include ${_input})
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/pch_dummy.cpp
${_dummy_str})
SET(${out_command}
${CMAKE_CXX_COMPILER} ${_compile_FLAGS} /c
/Fp${_native_output} /Yc${_native_input} pch_dummy.cpp
)
#/out:${_output}
ENDIF(CMAKE_COMPILER_IS_GNUCXX)
ENDMACRO(_PCH_GET_COMPILE_COMMAND )
MACRO(_PCH_GET_TARGET_COMPILE_FLAGS _cflags _header_name _pch_path )
FILE(TO_NATIVE_PATH ${_pch_path} _native_pch_path)
message
Re: [CMake] -fPIC and precompiled header
Hi Maik,
Thanks for the Christmas present ;-) I tried your code with gcc.
The following issues/suggestions came to my mind:
1) It seems to me (and it worked for me) that you don't need to
have CMAKE_CURRENT_BINARY_DIR in the include path if you change
the target cflags determination into
set(${_cflags} -include
${CMAKE_CURRENT_BINARY_DIR}/${_header_name} -Winvalid-pch )
which means the -include flag sees the complete path.
2) the include directory options seem to be missing in _PCH_GET_COMPILE_FLAGS
would you not need something like
GET_DIRECTORY_PROPERTY(DIRINC INCLUDE_DIRECTORIES )
FOREACH(item ${DIRINC})
LIST(APPEND ${_out_compile_flags} ${_PCH_include_prefix}${item})
ENDFOREACH(item)
furthermore I suppose you should replace all _compile_FLAGS variables
in this function by ${_out_compile_flags}. It works as you do it but having a
macro argument
and not using it makes things really confusing.
3) What happens if an dependency of the precompiled include file changes?
YOu could run a compiler command to determine the dependencies on
configure time, but this seems not completely fool proof.
I suggest to add the following target in ADD_PRECOMPILED_HEADER
GET_TARGET_PROPERTY(_targetType ${_PCH_current_target} TYPE)
SET(PHC_MASTER_INCLUDE_FILE ${_input})
CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/cmModules/PCHCheckDependencies.cxx.in
${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_gchdep.cxx)
IF(${_targetType} STREQUAL SHARED_LIBRARY)
ADD_LIBRARY(${_targetName}_gchdep SHARED
${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_gchdep.cxx)
ELSE(${_targetType} STREQUAL SHARED_LIBRARY)
ADD_LIBRARY(${_targetName}_gchdep STATIC
${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_gchdep.cxx)
ENDIF(${_targetType} STREQUAL SHARED_LIBRARY)
and add ${_targetName}_gchdep as dependency to
ADD_CUSTOM_COMMAND(
OUTPUT ${_output}
COMMAND ${_command}
DEPENDS ${_input} ${_outdir} ${CMAKE_CURRENT_BINARY_DIR}/${_name}
${_targetName}_gchdep
)
PCHCheckDependencies.cxx.in contains just
#include ${PHC_MASTER_INCLUDE_FILE}
int PHC_MASTER_INCLUDE_FILE_testfunction()
{
return 0;
}
it does not take much time to compile ( for my project much less then the
generation
of the precompiled headers) and as far as I can see it is the most simple way
to automatically
handle the dependencies.
4)
your test for pch support seems a bit sloppy - anything besides
GXX is msvc ??
Anyway a big thank you for this macro
Cheers,
Axel
On Saturday 23 December 2006 11:26, Maik Beckmann wrote:
Am Mittwoch, den 20.12.2006, 17:53 +0100 schrieb frederic heem:
Hi,
Is there a nice way to find out if a target is using -fPIC ?
Indeed, this information is needed for generating compiled header.
At the moment, a kludge is to use the following code:
#If the target is a shared library, add -fPIC to compile
GET_TARGET_PROPERTY(_targetType ${_targetName} TYPE)
IF(${_targetType} STREQUAL SHARED_LIBRARY)
SET(_compile_FLAGS ${_compile_FLAGS} -fPIC)
ENDIF(${_targetType} STREQUAL SHARED_LIBRARY)
This works but is not a proper solution, one shall not know in which
case -fPIC is used or not.
Thanks,
Frederic Heem
I ran into this problem and your solutions works like a charm.
I also worked on msvc support(see attached file), but it only work if
CMAKE_BUILD_TYPE equals Release, since /Fd wants to add debugging
informations and fails due to inconsitent pdb files. If someone know's
more about this issue, please give me a hint.
merry Christmas, Maik
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Friday 22 December 2006 00:11, Andreas Schneider wrote: Axel Roebel wrote: Hi Andreas, Hi Axel, Happy new year everybody! obviously you've found a simpler method to achieve the same goal and your tests are more complete. It seems to me, however, that it has the same weaknesses as my current version - libperl.so is not found (at least not on Fedora and redhat CentOS, I didn't recognize because swig does not need it) Why isn't it found, what path do they use? same as the include files siter.roebel: (~) 498 locate libperl.so /usr/lib/perl5/5.8.2/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.1/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so - changing the perl interpreter would not change the libraries and include paths (as Tristan pointed out for my second FindSWIG.cmake) If I find the time I will fix these issues and put them into the bug fix. I will use your simpler version of determining perl variables and will add the variables you test as well. just use my FindPerl.cmake and modify it :) Thanks, I'll do that. Axel -- andreas -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Monday 18 December 2006 13:43, Andreas Schneider wrote: Axel Roebel wrote: Hi, Hello, I just started to add swig support to our project http://sourceforge.net/projects/sdif. The project supports swig bindings to perl, python and java. I instantly tried the available cmake modules: notably FindSWIG.cmake and FindPerlLibs.cmake I was pretty astonished to find that these two macros do not work at all, because most of the important information that is necessary to find the components is hardcoded using fixed version numbers (that are already out of date) Maybe you want to take a look at http://svn.gpsdrive.cc/gpsdrive/trunk/cmake/Modules/FindPerlLibs.cmake Hi Andreas, obviously you've found a simpler method to achieve the same goal and your tests are more complete. It seems to me, however, that it has the same weaknesses as my current version - libperl.so is not found (at least not on Fedora and redhat CentOS, I didn't recognize because swig does not need it) - changing the perl interpreter would not change the libraries and include paths (as Tristan pointed out for my second FindSWIG.cmake) If I find the time I will fix these issues and put them into the bug fix. I will use your simpler version of determining perl variables and will add the variables you test as well. Thanks for the feedback. -- andreas -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to get a variable that is defined in another CMakeLists.txt file
On Wednesday 20 December 2006 23:38, Mike Jackson wrote:
So in Project B's CMakeLists.txt file I have:
SUBDIRS(${PROJECT_SOURCE_DIR}/Project_A)
ADD_EXECUTABLE( MyProgram ${SOURCES})
TARGET_LINK_LIBRARIES( MyProgram ${A_LIB_OUTPUT_NAME})
As far as I understand it variables defined in the main directory
(=CMakeLists.txt) will be defined
in the sub directory (=CMakeLists.txt), BUT, variables defined in sub
directories will NOT be
defined in the main directory This creates scopes for variables like in most
other programming languages.
so this should do it. (It does for me, however I use ADD_SUBDIRECTORY)
SUBDIRS(${PROJECT_SOURCE_DIR}/Project_A)
GET_DIRECTORY_PROPERTY(outvar DIRECTORY ${PROJECT_SOURCE_DIR}/Project_A
DEFINITION A_LIB_OUTPUT_NAME)
ADD_EXECUTABLE( MyProgram ${SOURCES})
TARGET_LINK_LIBRARIES( MyProgram ${outvar})
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode Generator
On Thursday 14 December 2006 18:03, Sean McBride wrote: On 2006-12-14 14:40, Axel Roebel said: I would suggest to change this order in cmake because having debug as default in a software distribution seems not so appropriate given that you cannot assume that all people that may download and compile your software with Xcode are really knowing what they are doing. Good idea... did you file a bug? Done. -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] digging in the dark corners of the command line argument interpreter
Dear CMakers
I run into a little problem with the command line flag -D.
I'll often use the command line flag -D to pass variables to cmake.
Because typing long names like
-DTT_EXECUTABLE:PATH=tt
is boring I was pretty happy to see that I could do
-DTT_EXECUTABLE=tt
as well. Before you start shortcutting I have to add
some salt to this nice soup because unfortunately
it turns out that this nearly always works besides
if in CMakeLists.txt I do a FIND_PROGRAM. For example with
MESSAGE(varstate: ${TT_EXECUTABLE})
FIND_PROGRAM(TT_EXECUTABLE NAMES whatever)
MESSAGE(varstate: ${TT_EXECUTABLE})
what happens is
$ cd /home/roebel/tmp/
$ cmake . -DTT_EXECUTABLE=whatever
varstate: whatever
varstate: /home/roebel/tmp/whatever
which shows that FIND_PROGRAM replaced the content of variable TT_EXECUTABLE
by $PWD/${TT_EXECUTABLE} which is nonsense most of the time.
After some more digging I found that with
-DTT_EXECUTABLE=whatever no cache variable is created
so the variable seems to be in kind of a zomby state.
However, it turns out that
cmake . -DTT_EXECUTABLE:=whatever
works correctly creating a string type cache variable.
So the questions are,
1. what is
-DTT_EXECUTABLE=whatever
supposed to do in contrast to
-DTT_EXECUTABLE:=whatever
or the book version
-DTT_EXECUTABLE:STRING=whatever
2.
can I rely on -DTT_EXECUTABLE:=whatever to work or am I still abusing a
current weakness of the command line type check.
Thanks for any illumination!
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] digging in the dark corners of the command line argument interpreter
On Wednesday 13 December 2006 16:47, Alan W. Irwin wrote:
On 2006-12-13 10:29+0100 Axel Roebel wrote:
Dear CMakers
I run into a little problem with the command line flag -D.
I'll often use the command line flag -D to pass variables to cmake.
Because typing long names like
-DTT_EXECUTABLE:PATH=tt
is boring I was pretty happy to see that I could do
-DTT_EXECUTABLE=tt
as well. Before you start shortcutting I have to add
some salt to this nice soup because unfortunately
it turns out that this nearly always works besides
if in CMakeLists.txt I do a FIND_PROGRAM. For example with
MESSAGE(varstate: ${TT_EXECUTABLE})
FIND_PROGRAM(TT_EXECUTABLE NAMES whatever)
MESSAGE(varstate: ${TT_EXECUTABLE})
what happens is
$ cd /home/roebel/tmp/
$ cmake . -DTT_EXECUTABLE=whatever
varstate: whatever
varstate: /home/roebel/tmp/whatever
which shows that FIND_PROGRAM replaced the content of variable
TT_EXECUTABLE by $PWD/${TT_EXECUTABLE} which is nonsense most of the
time.
After some more digging I found that with
-DTT_EXECUTABLE=whatever no cache variable is created
so the variable seems to be in kind of a zomby state.
However, it turns out that
cmake . -DTT_EXECUTABLE:=whatever
works correctly creating a string type cache variable.
So the questions are,
1. what is
-DTT_EXECUTABLE=whatever
supposed to do in contrast to
-DTT_EXECUTABLE:=whatever
or the book version
-DTT_EXECUTABLE:STRING=whatever
2.
can I rely on -DTT_EXECUTABLE:=whatever to work or am I still abusing a
current weakness of the command line type check.
Thanks for any illumination!
All your examples above have the path first. Just out of curiosity, what
happens if you use the recommended style with the path on the end, i.e.,
cmake [options] path-to-source
all the same !
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 Yorick front-end to PLplot (yplot.sf.net); 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
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Xcode Generator
Hi we are working on a release for our SDIF library (http://sourceforge.net/projects/sdif) which should for the first time use cmake instead of autotools as its configuration system. Everything works fine for unix makefiles (on Linux and Mac OS X) Now, we tried the Xcode generator and we am having some minor problems with it. 1) It appears that the default build style in the Xcode project is set to debug while for my makefile build system it always is set to release. So we wonder why these two are different. Note, that we set CMAKE_BUILD_TYPE to release. 2) In the cmake project there exists a sub directory holding swig wrappers that are not included in the all target. This is accomplished by ADD_SUBDIRECTORY(swig EXCLUDE_FROM_ALL) now while in the makefile generator we still have the swig targets if we just enter the sub directories in the the Xcode project the targets are not available at all. They show up though if we remove EXCLUDE_FROM_ALL from the the ADD_SUBDIRECTORY call above. Because the swig targets are somewhat experimental we don't like to have them in the default target. Is there a way to exclude them from all but still have the targets available? Another option may be to have them in the all target but set a different target as default target. Is this possible? Thanks for any feedback, -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: [MODULES][UseSWIG] Dependencies automagically computed!
On Monday 11 December 2006 21:52, Tristan Carel wrote:
On 12/9/06, Axel Roebel [EMAIL PROTECTED] wrote:
Tristan Carel wrote:
Hi Swig lovers,
... cut
DEPENDS ${SWIG_MODULE_${name}_EXTRA_DEPS}
Yes, It's exactly what I meant in my previous post when I wrote:
[...] it's hard to maintain dependencies of the wrapper
generated by swig because the developper has to manually update the
CMakeLists.txt [...]
I asked to CMake maintainers to add the SWIG_MODULE_${name}_EXTRA_DEPS
variable few months ago, but I didn't know that it could be done
automatically with the `swig -M' option.
I submitted a patch for `UseSWIG.cmake' in the bug tracker. You say
that the dependencies are not computed by default by the
`SWIG_ADD_SOURCE_TO_MODULE' macro. You probably patched your
`UseSWIG.cmake' before but ... did you?
Sorry, unfortunately I did not have all my computers updated to cmake 2.4.5
and so it apears I started with UseSWIG.cmake that comes with cmake 2.4.3.
After your remark I checked UseSWIG.cmake from 2.4.5 and that one
does have the missing DEPENDS line already.
So everything works ok then.
to the ADD_CUSTOM_COMMANDS in SWIG_ADD_SOURCE_TO_MODULE.
The added dependencies are pretty cool then. So I suppose you just
forgot to actually use them?
I used them but now I'm fed up to update it each time I modify the
inclusions of the swig file.
If you add the DEPENDS line you probably need to check for
the case that ${SWIG_MODULE_${name}_EXTRA_DEPS}
is empty. Otherwise DEPENDS will probably complain if the
argument is an empty list. I have this error all the time
for COMPILE_FLAGS, but I am not sure whether
DEPENDS behaves similarly.
I've already used the `SWIG_ADD_SOURCE_TO_MODULE' without using the
`${SWIG_MODULE_${name}_EXTRA_DEPS' feature so I guess it properly
works even if the variable is empty.
Good to know.
Thanks for the effort with UseSWIG.cmake,
it really works great.
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: [MODULES][UseSWIG] Dependencies automagically computed!
I have some more observations :
1)
the error message SWIG_GET_WRAPPER_DEPENDENCIES
uses ${SWIG} instead of ${SWIG_EXECUTABLE}
MESSAGE(SEND_ERROR Command \${SWIG} -MM -MF ${swig_getdeps_depsfile}
${swig_getdeps_extra_flags} -${language} -o ${genWrapper} $\
{swig_getdeps_include_dirs} ${swigFile}\ failed with output:
\n${swig_getdeps_error})
2)
The command line used to find the dependencies
does not use the same flags as the command line used to
compile the files:
In the latter you have
${swig_source_file_flags}
${CMAKE_SWIG_FLAGS}
${swig_special_flags}
${swig_extra_flags}
${swig_include_dirs}
while in the former you only use
${swig_getdeps_extra_flags} -${language}
in some of my projects I use ${CMAKE_SWIG_FLAGS}
to pass include directories which fails with an error
during dependency generation because some of the
include files are not found. While you may argue that
I should use the INCLUDE_DIRECTORIES command I preferred
${CMAKE_SWIG_FLAGS} because that would prevent
the c++ compiler from searching in the project common
swig include directories.
Without knowing the swig wrapper generator extremely well, I wonder
whether having different flags in these two stages
is not asking for a lot of trouble.
Cheers,
On Monday 11 December 2006 21:52, Tristan Carel wrote:
On 12/9/06, Axel Roebel [EMAIL PROTECTED] wrote:
Tristan Carel wrote:
Hi Swig lovers,
Axel had the great idea to use the -swiglib option in order to improve
the module's efficiency to properly fill the prerequesites variables.
I guess it is the perfect example of using a tool to perform its
`configure' part.
On the other hand, it's hard to maintain dependencies of the wrapper
generated by swig because the developper has to manually update the
CMakeLists.txt each time a change relative to the file inclusions in
the main swig file is performed. But Swig provides a couple of
options: -M, -MM, -MF, ...
which have the same behavior than gcc's: compute the dependencies for
us, lazy developpers!
So I submitted a new macro in the `UseSWIG.cmake' few days ago:
http://www.cmake.org/Bug/bug.php?op=showbugid=4147pos=7
# SWIG_GET_WRAPPER_DEPENDENCIES(swigFile genWrapper language
DEST_VARIABLE) # - Put dependencies of the wrapper genWrapper
generated by swig from # swigFile in DEST_VARIABLE
A full description (including behavior, use cases) is available on the
bug tracker.
So as Axel wrote:
Any comments or volunteers to try?
Hi Tristan,
do I get the idea right that you want that the wrapper will be recreated
whenever any of its dependencies changed? That would be really nice!
So I tried the usecase 1 (because usecase 2 is too involved for me ;-)
like
SWIG_ADD_MODULE(eaSDIF perl ${INTERFACE_SRC} )
SWIG_LINK_LIBRARIES(eaSDIF ${PERL_LIBRARIES} Easdif)
however it seems I don't get any dependencies besides the
main interface file ${INTERFACE_SRC}.
I do get them if I add
DEPENDS ${SWIG_MODULE_${name}_EXTRA_DEPS}
Yes, It's exactly what I meant in my previous post when I wrote:
[...] it's hard to maintain dependencies of the wrapper
generated by swig because the developper has to manually update the
CMakeLists.txt [...]
I asked to CMake maintainers to add the SWIG_MODULE_${name}_EXTRA_DEPS
variable few months ago, but I didn't know that it could be done
automatically with the `swig -M' option.
I submitted a patch for `UseSWIG.cmake' in the bug tracker. You say
that the dependencies are not computed by default by the
`SWIG_ADD_SOURCE_TO_MODULE' macro. You probably patched your
`UseSWIG.cmake' before but ... did you?
to the ADD_CUSTOM_COMMANDS in SWIG_ADD_SOURCE_TO_MODULE.
The added dependencies are pretty cool then. So I suppose you just
forgot to actually use them?
I used them but now I'm fed up to update it each time I modify the
inclusions of the swig file.
If you add the DEPENDS line you probably need to check for
the case that ${SWIG_MODULE_${name}_EXTRA_DEPS}
is empty. Otherwise DEPENDS will probably complain if the
argument is an empty list. I have this error all the time
for COMPILE_FLAGS, but I am not sure whether
DEPENDS behaves similarly.
I've already used the `SWIG_ADD_SOURCE_TO_MODULE' without using the
`${SWIG_MODULE_${name}_EXTRA_DEPS' feature so I guess it properly
works even if the variable is empty.
CU
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: [MODULES][UseSWIG] Dependencies automagically computed!
On Tuesday 12 December 2006 16:36, Tristan Carel wrote: I added a RC3 version on the bt (http://www.cmake.org/Bug/bug.php?op=showbugid=4147) which takes care of your comments. It should be all right now. Do you copy? Not that it is extremely important, but the error message still does not list the CMAKE_SWIG_FLAGS. -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] [MODULES][UseSWIG] Dependencies automagically computed!
Tristan Carel wrote:
Hi Swig lovers,
Axel had the great idea to use the -swiglib option in order to improve
the module's efficiency to properly fill the prerequesites variables.
I guess it is the perfect example of using a tool to perform its
`configure' part.
On the other hand, it's hard to maintain dependencies of the wrapper
generated by swig because the developper has to manually update the
CMakeLists.txt each time a change relative to the file inclusions in
the main swig file is performed. But Swig provides a couple of
options: -M, -MM, -MF, ...
which have the same behavior than gcc's: compute the dependencies for
us, lazy developpers!
So I submitted a new macro in the `UseSWIG.cmake' few days ago:
http://www.cmake.org/Bug/bug.php?op=showbugid=4147pos=7
# SWIG_GET_WRAPPER_DEPENDENCIES(swigFile genWrapper language
DEST_VARIABLE) # - Put dependencies of the wrapper genWrapper generated
by swig from # swigFile in DEST_VARIABLE
A full description (including behavior, use cases) is available on the
bug tracker.
So as Axel wrote:
Any comments or volunteers to try?
Hi Tristan,
do I get the idea right that you want that the wrapper will be recreated
whenever any of its dependencies changed?
That would be really nice!
So I tried the usecase 1 (because usecase 2 is too involved for me ;-)
like
SWIG_ADD_MODULE(eaSDIF perl ${INTERFACE_SRC} )
SWIG_LINK_LIBRARIES(eaSDIF ${PERL_LIBRARIES} Easdif)
however it seems I don't get any dependencies besides the
main interface file ${INTERFACE_SRC}.
I do get them if I add
DEPENDS ${SWIG_MODULE_${name}_EXTRA_DEPS}
to the ADD_CUSTOM_COMMANDS in SWIG_ADD_SOURCE_TO_MODULE.
The added dependencies are pretty cool then. So I suppose you just
forgot to actually use them?
If you add the DEPENDS line you probably need to check for
the case that ${SWIG_MODULE_${name}_EXTRA_DEPS}
is empty. Otherwise DEPENDS will probably complain if the
argument is an empty list. I have this error all the time
for COMPILE_FLAGS, but I am not sure whether
DEPENDS behaves similarly.
Cheers,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Thursday 07 December 2006 22:57, Axel Roebel wrote:
3. in the CMake/Modules/readme.txt, you can read:
If the QUIET option is given to the command it will set the variable
XXX_FIND_QUIETLY to true before loading the FindXXX.cmake module.
but you use: FIND_SWIG_QUIETLY
yes in fact I didn't read that file.
I have now read all the stuff in the readme I find that the handling of
REQUIRED and QUIETKY flags was still not correct in FindSWIG.cmake
Apparently this is a copy and paste error and many of the Find packages
are not dealing with these flags correctly.
The FindBoost.cmake for example does the same as the last version of the
FindSWIG.cmake
IF(NOT Boost_FOUND)
IF(NOT Boost_FIND_QUIETLY)
MESSAGE(STATUS Boost was not found. ${BOOST_DIR_MESSAGE})
ELSE(NOT Boost_FIND_QUIETLY)
IF(Boost_FIND_REQUIRED)
MESSAGE(FATAL_ERROR Boost was not found. ${BOOST_DIR_MESSAGE})
ENDIF(Boost_FIND_REQUIRED)
ENDIF(NOT Boost_FIND_QUIETLY)
ENDIF(NOT Boost_FOUND)
This boils down to having a fatal error only if the QUIET flag was given
together with the REQUIRED flag, which I suppose was not intended.
In FindVTK.cmake we see
IF(NOT VTK_FIND_QUIETLY)
MESSAGE(FATAL_ERROR ${VTK_DIR_MESSAGE})
ELSE(NOT VTK_FIND_QUIETLY)
IF(VTK_FIND_REQUIRED)
MESSAGE(FATAL_ERROR ${VTK_DIR_MESSAGE})
ENDIF(VTK_FIND_REQUIRED)
ENDIF(NOT VTK_FIND_QUIETLY)
which means we always get a fatal error which is also not what the readme
suggests.
I updated the FindSWIG.cmake to do
IF(NOT SWIG_FOUND)
IF(NOT SWIG_FIND_QUIETLY)
IF(SWIG_FIND_REQUIRED)
MESSAGE(FATAL_ERROR SWIG was not found. Please specify Swig executable
location)
ELSE(SWIG_FIND_REQUIRED)
MESSAGE(STATUS SWIG was not found. Please specify Swig executable
location)
ENDIF(SWIG_FIND_REQUIRED)
ENDIF(NOT SWIG_FIND_QUIETLY)
ENDIF(NOT SWIG_FOUND)
which seems me to do what the readme suggests with the interpretation that
QUIET takes precedence over REQUIRED.
Alain Irwin wrote:
Therefore, I would replace
MESSAGE(STATUS using swig ${SWIG_DIR})
with
MESSAGE(STATUS using ${SWIG_EXECUTABLE} with SWIG_DIR = ${SWIG_DIR})
Because every project maintainer will probably have its own desires (from
Tristan who wants nothing
to Alan who wants more) I removed all positive status messages in the last
version.
The calling CMakeLists.txt can output the desired
information using the result variables much more flexible then the
FindSWIG.cmake could
do.
Cheers,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
On Wednesday 06 December 2006 17:36, Axel Roebel wrote: I will test the module tomorrow. Could you please put a RC2 of the `FindSWIG.cmake' on the bug tracker? That may take a day or too. I'll let you know. There it is, called FindSWIG.cmake-2 It should take care of all your comments, please have a look. I would especially be interested to hear if it works on windows. I can only try linux and Mac OS X Thanks, -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
Bill Hoffman wrote:
Axel Roebel wrote:
1. Look for swig executable
2. use `swig -swiglib' to get the swiglib path
3. FIND_PATH(SWIG_DIR swig.swg ${SWIG_outlib} /usr/share/swig1.3 ...)
could you tell me why you add this path
/usr/share/swig1.3 ?
This is a an old module, the FIND_* stuff has changed a lot since then.
For instance, the FIND_* stuff automatically adds /usr/bin, /usr/local/bin,
and other system paths for the architecture that is running. What is
needed is the PATH_SUFFIXES option to FIND_* so that cmake will know to
look for swigVersionNumbers in all those system paths. So, the listed
paths in the FIND_* are not the whole picture, and in most cases are not
even needed at all.
You are seriously suggesting to add something like
FIND_PATH(SWIG_DIR swig.swg PATH_SUFFIXES share/swig/1.3.29 share/swig/1.3.30
share/swig/1.3.30 share/swig/1.3.31 share/swig/1.3.31 share/swig/1.3.32
share/swig/1.3.33 share/swig/1.3.34 share/swig/1.3.35
share/swig/1.4.0 share/swig/1.4.1 share/swig/1.4.2
)
instead of
FIND_PATH(SWIG_DIR swig.swg PATH ${SWIG_outlib})
knowing that apparently some month ago (or for some
operating systems) it was
share/swig1.3
that one had to use?
It seems to me that the only reliable way here
is the executable. If the executable does not know the installation directory
it cannot do anything and we should consider SWIG to be not installed.
Before I update the version in the bug tracker I would like to know
whether having
FIND_PATH(SWIG_DIR SWIGConfig.cmake PATH ${SWIG_outlib})
does make any sense in a FindSWIG.cmake.
From the documentation I understand that
in case the project provides a SWIGConfig.cmake
it should have set SWIG_DIR already and
FindSWIG would not have been called?
Cheers,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindPerlLibs.cmake and FindSwig.cmake outdated!
Hi, I just started to add swig support to our project http://sourceforge.net/projects/sdif. The project supports swig bindings to perl, python and java. I instantly tried the available cmake modules: notably FindSWIG.cmake and FindPerlLibs.cmake I was pretty astonished to find that these two macros do not work at all, because most of the important information that is necessary to find the components is hardcoded using fixed version numbers (that are already out of date) I added patched version of these macros to bug reports 4145 4146 in the cmake bug database. These patched versions are completely backwards compatible (they use the wrong and fixed path locations first before they fall back to the new scheme and use the same variables to communicate results) The idea of the new procedure is to base everything on the FIND_PROGRAM macros that searches for the perl/swig binaries and (if found) asks the binary via inplace scripts (perl)/command line options (swig) all the directory locations that are needed. This approach is very flexible because by simply setting PERL_EXECUTABLE or SWIG_EXECUTABLE on the command line (or the cmake gui) one can select an arbitrary perl/swig version that is installed on the system. Any comments or volunteers to try? -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
re: [CMake] Mac application bundles resources
On Friday 03 November 2006 14:03, [EMAIL PROTECTED] wrote:
Message: 1
Date: Thu, 2 Nov 2006 21:44:32 +
From: Matthew J Smith [EMAIL PROTECTED]
Subject: [CMake] Mac application bundles resources
To: cmake@cmake.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Hi everyone,
I've been approached to get a Mac application bundle built for the
Speedcrunch calculator app (speedcrunch.digitalfanatics.org). The
app uses Qt 4 and is normally built using qmake, but the developers
have started using CMake, which for the X11 install model (binaries
in /usr/bin, resources in /usr/share) works fine. However, although
I can get CMake to build an application bundle, I can't find any
instructions as to how to get the resources to install in the
Resources directory within the bundle.
Does CMake even have this feature, and if so, can anyone tell me how
to do this? I'm using version 2.4.3. I've attached my CMakeLists.txt.
Matt Smith
--
http://www.blogistan.co.uk/qt/
I don't think that exists.
Here a hand made solution:
What I do to install an icon file is
SET(EXECUTABLE_OUTPUT_PATH ...)
ADD_EXECUTABLE(svp_kernel_app MACOSX_BUNDLE ${prgSOURCES}
${SHOW_VERSION_PRG_K} )
ADD_CUSTOM_TARGET(svp_kernel COMMAND cp
${CMAKE_CURRENT_SOURCE_DIR}/../../distribution/supervp.icns
${EXECUTABLE_OUTPUT_PATH}/supervp${DEBUGEXT}.app/Contents/
Resources)
ADD_DEPENDENCIES(svp_kernel svp_kernel_app)
This means a bundle target is used to create the binaries in the app
and the custom target is used to copy the icon. The only target I use during
the build stage
is svp_kernel which first creates the bundle binary and then copies the icon.
You may as well try to use configure_file to put the resources in place.
It seems to me cmake is creating the bundle directory during cmake run time
and the make system will never touch these directories later again.
So I suppose you can call configure_file to put
all resources in the right place when running cmake.
You need to know where and how to put them correctly
using command line tools though.
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] removing a target from the all target
On Tuesday 31 October 2006 15:34, Bill Hoffman wrote: Brad King wrote: Axel Roebel wrote: I wonder whether anybody sees a simpler solution to the problem, like a simple target property that will remove the traget from the list of targets linked to the all target. In CMake from CVS and in the upcoming 2.4.4 release you can do ADD_EXECUTABLE(myexe EXCLUDE_FROM_ALL myexe.c) That was what I thought should exist. So the future is very shiny. and similarly for libraries. There are also now some install/fast targets that will not do the checks. So I'll use this for the time being. Thank's a lot for the infos, AND for the great tool! Axel -Bill -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] removing a target from the all target
Hello, I have a number of libraries and executable targets in my project where only the executable targets are commonly used for installation. The libraries implement the same code as the executables and will be used only under very specific conditions. Unfortunately cmake creates makefiles that apparently will build all targets before proceeding to do the installation. This means that even if I don't have an install rule for a target, it will nevertheles be build before the install rule is excuted. Given the fact that a build for the libraries that are not going to be installed takes 15 minutes, I wonder which options I have to unlink them from the list of targets to be build prior to installation. An obvious solution would be to move all the build instructions for these libraries into a sub directory which is added with the exclude from all option. A second solution is the creation of optional targets using the option macros. This however, would require reconfiguration, which I don't like to be necessary because the people that need ton compile the library version of the project will not understand what they have to do. I wonder whether anybody sees a simpler solution to the problem, like a simple target property that will remove the traget from the list of targets linked to the all target. Thanks for any comment, -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MACOSX_DEPLOYMENT_TARGET
On Wednesday 11 October 2006 15:28, you wrote: Axel Roebel wrote: The problem is that to my knowledge the only way to communicate the deployment target to gcc is via environment variables. I admit this is a really strange way (probably its save to say silly) to select compiler options, but as far as I know, this is the way it is done in Xcode. And it is the way it is suggested by apple for makefiles see (at the very bottom ) http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_ development/Using/chapter_3_section_2.html#//apple_ref/doc/uid/20002000-11 14311-BABGCAAB This means in the makefile the compiler needs to be called as in target : MACOSX_DEPLOYMENT_TARGET=10.3 gcc ... so the question would be how to achieve this. I've the strong feeling it is not possible - is it? Try creating a shell script called gcc-osx-10.3 containing something like This is exactly what I do currently. I thought there would may be exist an easier way. I now see that my main problem is how I replace the compiler: I patch CMakeFiles/CMakeCCompiler.cmake from within CMakeLists.txt, while I probably should simply do SET(CMAKE_C_COMPILER path/gcc-osx-10.3) I think when I tried that with an older cmake like 2.2... this SET would not override the compiler. With 2.4.3 I still find the original compiler /usr/bin/gcc in the CMakeCache.txt but at least the build.cmake has the script. Thanks #!/bin/sh export MACOSX_DEPLOYMENT_TARGET=10.3 exec gcc $@ and then set that as your compiler. -Brad -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MACOSX_DEPLOYMENT_TARGET
On Tuesday 10 October 2006 23:20, Sean McBride wrote: On 2006-10-10 21:47, Axel Roebel said: ... I'm pretty sure there is no way to specify per-architecture variants of these things. I believe this was discussed in bug 2492, which you may want to read (its long). Thanks, I've read that. But I don't want per architecture variants. I want to configure my build for the native architecture I suggest filing a bug. I also think this would be a good feature for CMake to have, though personally I don't need it. I think it comes down to CMake's lack of cross-compilation support. that's not the point. I am happy with compiling natively on each machine and I create the universal by means of a shell script. This is no cross compilation issue, because MACOSX_DEPLOYMENT_TARGET selects the compiler target system for the architecture of the build system The problem is that to my knowledge the only way to communicate the deployment target to gcc is via environment variables. I admit this is a really strange way (probably its save to say silly) to select compiler options, but as far as I know, this is the way it is done in Xcode. And it is the way it is suggested by apple for makefiles see (at the very bottom ) http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/Using/chapter_3_section_2.html#//apple_ref/doc/uid/20002000-1114311-BABGCAAB This means in the makefile the compiler needs to be called as in target : MACOSX_DEPLOYMENT_TARGET=10.3 gcc ... so the question would be how to achieve this. I've the strong feeling it is not possible - is it? -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
On Wednesday 31 May 2006 01:44, William A. Hoffman wrote: Yes, that is what I am talking about. I don't think it will be hard to implement, and I am sure any hard coded approach will be regretted a few months later. Also, cmake dir --help (will print the help for the given project) I understand that you don't like the hardcoded approach, still this is what made the configure interface so standardizing that now we discuss it here. There were hardly any configure scripts that would not provide some of the basic flags (at least --prefix) and the --enable/--disable syntax for the options. I understand as well that you want to make it as easy as possible and it obviously the handling of the OPTION variables requires parsing the CMakeLists.txt and the CMakeCache.txt, which would require some more effort than reading only the command line shortcut option file. So I would suggest to make the mapping --prefix - -DCMAKE_INSTALL_PREFIX --verbose - -DCMAKE_VERBOSE_MAKEFILE --build - -DCMAKE_BUILD_TYPE the default mapping which can be changed only if the user supplies a local configuration file which can only be used to extend the shortcut list. The option syntax using --enable-toto... is in fact a bit longer than -Dtoto= so we may live without it. And for the help we may rely on ccmake or cmake -i I think we have extensively discussed the issues and I will create a feature request such that you will not forget these suggestions. Kind regards -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Re: [CMake] Re: a ./configure shell script stub (Filipe Sousa)
Filipe Sousa filipe at ipb.pt wrote : I've been using a configure perl script that call cmake. I have this script compiled to configure.exe on windows. But I always use ccmake or cmakesetup because there are options that are enabled depending on other options and that can't be done in my scripts. I have these scripts for those who are used to configure make make install. This seems not correct to me! Given the CMakeLists.txt file project(test) IF(ONE) OPTION(TWO second level off) ENDIF(ONE) OPTION(ONE first level off) and calling cmake . -DONE=ON -DTWO=ON appears to create a perfectly configured project for me. (???) Moreover, relying on TWO being unset if ONE=OFF is not reliable anyway because switching ONE and TWO on and then later switching ONE off again leaves you with ONE=OFF and TWO=ON. -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Monday 29 May 2006 18:00, William A. Hoffman wrote: There is ccmake on UNIX and (the more powerful) cmakesetup on Windows for this job. What is missing is something like a qcmake, which would add a nice GUI to all available options. There is a wxWidgets GUI in CVS. The question is, would a GUI make the configure command line people happy, or will there always be a group that wants a -- style command line like configure. I'd say I would not profit from a GUI at all. There is no gain compared to ccmake. You will not be able to use it in shell scripts it and you cannot run it without interaction from the buildtool! -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: a ./configure shell script stub (William A. Hoffman)
I move this thread back into the user mailing list, because this is not promotion but interface design. Everybody would suffer if there are any errors in the command line interface organization! On Monday 29 May 2006 19:38, William A. Hoffman wrote: At 01:14 PM 5/29/2006, Axel Roebel wrote: On Monday 29 May 2006 18:01, William A. Hoffman wrote: To work with the options, it is best to use ccmake or CMakeSetup, or even cmake -i. To let people work from the command line we added the abilitiy to use -DVAR=VALUE from the command line. What this does is pre-load the CMakeCache.txt with the VAR. The VAR may or may not be even used in the project, cmake does not care. To implement --help correctly, you would have to configure the entire project first. My suggestion was to create an extra file that could be parsed at --help time, it would be small and easy to parse, and not require parsing the entire tree. It would provide a map from VAR name to --commandline name. It would be read by cmake and allow the project to specify its options in one place, and make it easier to implement --help, and add a way to specify a mapping from --option to a VAR name. Why not have the do nothing parser mode that displays all help strings of all options that are currently available? Together with the warning at the end of running cmake whenever the options did change, you would have all that is needed for command line operations! I suppose you could do this. I think there is still a need for some way to map from cmake variables to more command line friendly versions. Even if -help said you could do -DCMAKE_INSTALL_PREFIX=path, I don't think it would make people happy. They will want --prefix=. My idea was that there would be the special short cuts that are most often used: --prefix=* -DCMAKE_INSTALL_PREFIX=* --verbose -DCMAKE_VERBOSE_MAKEFILE --build=* -DCMAKE_BUILD_TYPE=* and besides that --foo_bar=* always maps into -DTOTO_FOO_BAR=* It could be nice to additionally have --enable_foo_bar - maps to the option FOO_BAR --disable_foo_bar - maps to the option FOO_BAR Maybe something like: set_variable_property(CMAKE_INSTALL_PREFIX COMMNAD_LINE_OPT --prefix) I don't think a configurable behavior is needed here. It is my opinion that there is no need for freedom for these things. It is more important to create standards. It should be as easy to type and as standardized as possible! There is also a logistics issue. The configure script is part of the project. cmake is not. So, to get help for a project in the do nothing parser mode, you will still have to tell cmake where the source tree is, and where the binary tree is (in case cmake has already been run). It will have to have the same options as actually running cmake. cmake --help ../path/to/source or cmake --help . (where . is a configured binary tree, or a source tree) I don't think it needs to be the same as configure. For out of source builds with configure you need to say ../path/to/source/configure --help or for in source builds ./configure --help from an ergonomic point of view this is basically the same with cmake having the clear advantage of being shorter to type then configure ;-) -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake Digest, Vol 25, Issue 43
On Friday 26 May 2006 18:50, [EMAIL PROTECTED] wrote: Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by default, each time, I have to set it manually and I find it quite annoying. It is a matter of taste. Some folks like to see pages and pages of output even if it builds nothing. Some folks only want to see what is being compiled and do not care about how it is being compiled. I think it is usually developers that like to see everything, and they are more likely to know how to change a setting. But users that just want to build the software, only want to build it and don't really care what is going on. It was felt that there are more users than developers, so that is why the default is off. I don't think that there is to much relation with developper or user. I am developper and I am building the same the configured project 100 times a day. I could not imagine something more annoying as seeing all the verbose messages for every compilation which would in fact distract me from the warnings in the compilation itself! I'd say make VERBOSE=1 is useful only as long as I debug the configuration. If this is fine it does not need to change and I don't want to see it ! -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cpack problems.
Hello,
I just tried the cpack program. It failed when executing
a post_install_script which is configured to access the installed libraries
and to rename them. Unfortunately this seems to be required if one wants to
install a static and a shared library of the same name.
Here the rename script template I use
FILE(GLOB INSTALLED_LIBNAME [EMAIL PROTECTED]@@INSTALL_LIB_DIR
@/[EMAIL PROTECTED]@*)
MESSAGE(INSTALLED_LIBNAME [EMAIL PROTECTED]@@INSTALL_LIB_DIR
@/[EMAIL PROTECTED]@*)
MESSAGE(INSTALLED_LIBNAME ${INSTALLED_LIBNAME})
STRING(REPLACE @BEFORE_RENAME@ @AFTER_RENAME@ INSTALLED_NAME_AFTER_RENAME $
{INSTALLED_LIBNAME})
EXEC_PROGRAM(@CMAKE_COMMAND@ ARGS -E copy ${INSTALLED_LIBNAME} ${INSTALLED_N
AME_AFTER_RENAME})
EXEC_PROGRAM(@CMAKE_COMMAND@ ARGS -E remove ${INSTALLED_LIBNAME})
which gets configured when running cmake. BEFORE_RENAME is the internal
name of the static library and after rename is the name desired after
installation.
The problem is that CMAKE_INSTALL_PREFIX used with cpack is different from the
CMAKE_INSTALL_PREFIX for real compilation, however, the configured Rename script
always uses the value that is appropriate for a real installation,
which is a value that I set with FORCE
in CMakeFiles.txt. I wonder whether there is any possibility to solve this
issue?
Now, in fact I don't want a binary distribution I only want a source
distribution such that
this issue would vanish automatically. However, I don't find a flag to tell
cpack to
only produce a source distribution. Is this possible?
I assume with a source distribution the user will be required to first
install cmake, wouldn't he?
Kind regards,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode generator problems
On Wednesday 03 May 2006 16:08, you wrote: Axel Roebel wrote: Thanks, in fact I found the problem! It is due to the repeated call of CollapseFullPath () which is used to determine the current absolute path cmDependsC.cxx for each dependency file with absolute path. This call is extremely costly on the mac. And it seems completely unnecessary because the current directory is never changed in cmDependsC.cxx. Initialization of the otherwise unused member Directory with the current directory and elemination of CollapseFullPath reduced dependency determination on the mac from 2 minutes too 8 seconds. This is even faster than for cmake 2.2.3. I have send a patch for closer inspection of the solution via the bug tracker. Thanks. I've fixed it. See this for details: http://www.cmake.org/Bug/bug.php?op=showbugid=3191 Super, thanks. I was sure you find a better solution! Axel -Brad -- Axel Roebel IRCAM Analysis/Synthesis Team Email: [EMAIL PROTECTED] | Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode generator problems
On Tuesday 02 May 2006 08:47, you wrote:
Hi,
Von: Axel Roebel [EMAIL PROTECTED]
...
real0m15.032s
user0m10.154s
sys 0m4.593s
with 2.4.1 compiled with type release ( which did not improve compared
to
none)
time /Users/roebel/src/cmake-2.4.1/bin/cmake -E cmake_depends Unix
Makefiles /Users/roebel/src/svp/build241
/Users/roebel/src/svp/build241/compile/KernelBuild
/Users/roebel/src/svp/build241/compile/KernelBuild/CMakeFiles/svp_kernel.di
r/DependInfo.cmake
real2m5.792s
user0m7.613s
sys 1m56.915s
This is nearly 10 times longer
Very strange. I use it extensively and for me there is no such slowdown.
There must be something else going on. Maybe have a look with strace or
callgrind ?
Interestingly the user processing time is faster, however,
system time has excessively increased. Note, that this has been
measured
on
the same system which was doing nothing else but the dependency check!
By the way, another problem with 2.4.1 is that the OUTPUT_NAME
of SET_TARGET_PROPERTIES is no longer working
(at least for unix makefiles)
Works for me:
add_executable(hello main.cpp)
set_target_properties(hello PROPERTIES OUTPUT_NAME blub)
Here I attach an extract of the strace output for the two calls mentioned
above, however, this time on a linux system because I don't know how to get a
trace on mac os x. Both extracts are related to the same source file
show_version.cxx:
Here the results for cmake 2.4.1
access(/home/roebel/src/mastersvp/svp2.8/src/svp/show_version.cxx, R_OK) = 0
open(/home/roebel/src/mastersvp/svp2.8/src/svp/show_version.cxx, O_RDONLY|
O_LARGEFILE) = 5
read(5, /**\n * Copy..., 8191) = 4540
read(5, , 8191) = 0
close(5)= 0
getcwd(/home/roebel/src/mastersvp/build241, 2048) = 36
stat64(/home/roebel/src/mastersvp/build241, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
access(/home/roebel/src/mastersvp/svp2.8/src/svp/preincluded.h, R_OK) = -1
ENOENT (No such file o
r directory)
access(compile/include/preincluded.h, R_OK) = -1 ENOENT (No such file or
directory)
getcwd(/home/roebel/src/mastersvp/build241, 2048) = 36
stat64(/home/roebel/src/mastersvp/build241, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
access(/home/roebel/src/mastersvp/svp2.8/compile/../include/preincluded.h,
R_OK) = -1 ENOENT (No
such file or directory)
getcwd(/home/roebel/src/mastersvp/build241, 2048) = 36
stat64(/home/roebel/src/mastersvp/build241, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
access(/home/roebel/src/mastersvp/svp2.8/src/modules/ampli/preincluded.h,
R_OK) = -1 ENOENT (No s
uch file or directory)
getcwd(/home/roebel/src/mastersvp/build241, 2048) = 36
stat64(/home/roebel/src/mastersvp/build241, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
access(/home/roebel/src/mastersvp/svp2.8/src/modules/analyse/preincluded.h,
R_OK) = -1 ENOENT (No
such file or directory)
and for cmake 2.2.3
access(/home/roebel/src/mastersvp/svp2.8/src/svp/show_version.cxx, R_OK) = 0
open(/home/roebel/src/mastersvp/svp2.8/src/svp/show_version.cxx, O_RDONLY|
O_LARGEFILE) = 4
read(4, /**\n * Copy..., 8191) = 4540
read(4, , 8191) = 0
close(4)= 0
access(/home/roebel/src/mastersvp/svp2.8/src/svp/preincluded.h, R_OK) = -1
ENOENT (No such file
or directory)
access(compile/include/preincluded.h, R_OK) = -1 ENOENT (No such file or
directory)
access(../svp2.8/compile/../include/preincluded.h, R_OK) = -1 ENOENT (No
such file or directory)
access(../svp2.8/src/modules/ampli/preincluded.h, R_OK) = -1 ENOENT (No such
file or directory)
access(../svp2.8/src/modules/analyse/preincluded.h, R_OK) = -1 ENOENT (No
such file or directory
)
access(../svp2.8/src/modules/control/preincluded.h, R_OK) = -1 ENOENT (No
such file or directory
)
access(../svp2.8/src/modules/filtre/preincluded.h, R_OK) = -1 ENOENT (No
such file or directory)
access(../svp2.8/src/modules/icanal/preincluded.h, R_OK) = -1 ENOENT (No
such file or directory)
access(../svp2.8/src/modules/idata/preincluded.h, R_OK) = -1 ENOENT (No such
file or directory)
access(../svp2.8/src/modules/mixer/preincluded.h, R_OK) = -1 ENOENT (No such
file or directory)
access(../svp2.8/src/modules/module/preincluded.h, R_OK) = -1 ENOENT (No
such file or directory)
access(../svp2.8/src/modules/ocanal/preincluded.h, R_OK) = -1 ENOENT (No
such file or directory)
access(../svp2.8/src/modules/resampler/preincluded.h, R_OK) = -1 ENOENT (No
such file or directo
ry)
access(../svp2.8/src/modules/synthese/preincluded.h, R_OK) = -1 ENOENT (No
such file or director
Obviously cmake 2.4.1 is much less efficient needing three times as many
system calls for testing a single file than cmake 2.2.3. The repeated
stat and getcwd calls for the same directory seem highly redundant.
Cheers,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Re: [CMake] Xcode generator problems
On Tuesday 02 May 2006 17:22, you wrote: Here I attach an extract of the strace output for the two calls mentioned above, however, this time on a linux system because I don't know how to get a trace on mac os x. More info on that here: http://www.cmake.org/Wiki/CMake_Platform_Dependent_Issues You have to use ktrace/kdump HTH Mathieu Thanks, in fact I found the problem! It is due to the repeated call of CollapseFullPath () which is used to determine the current absolute path cmDependsC.cxx for each dependency file with absolute path. This call is extremely costly on the mac. And it seems completely unnecessary because the current directory is never changed in cmDependsC.cxx. Initialization of the otherwise unused member Directory with the current directory and elemination of CollapseFullPath reduced dependency determination on the mac from 2 minutes too 8 seconds. This is even faster than for cmake 2.2.3. I have send a patch for closer inspection of the solution via the bug tracker. Cheers, -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Xcode generator problems
Hi,
I just tried to generate Xcode project files for some of my
cmake supported sources. I encountered three problems:
1) I tried to communicate -framework Carbon flags
to the link stage. I tried
SET(LINK_FRAMEWORKS -framework Accelerate -framework Carbon)
SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE ${CMAKE_SHARED_LINKER_FLAGS_RELEASE}
${LINK_FRAMEWORKS} CACHE STRING Linker flags FORCE)
SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE ${CMAKE_SHARED_LINKER_FLAGS_RELEASE}
${LINK_FRAMEWORKS} CACHE STRING Linker flags FORCE)
as well as
SET_TARGET_PROPERTIES(svpmain${DEBUGEXT} PROPERTIES LINKER_LANGUAGE CXX
OUTPUT_NAME svp LINK_FLAGS ${LINK_FRAMEWORKS})
In both cases the generated project does not use the framework flags I asked
for. The unix makefile generator, however, works properly. Maybe there is a
reason or another mechanism that should be used?
The second problem is more annoying:
From time to time the compiler fails completely and the error.log shows the
error message:
...
setenv VERSION_INFO_STRING \@(#)PROGRAM:XCODE_DEPEND_HELPER PROJECT:CMAK
E_TRY_COMPILE- DEVELOPER:roebel BUILT:\ __DATE__ \ \ __TIME__ \\
setenv WARNING_CFLAGS -Wmost -Wno-four-char-constants
-Wno-unknown-pragmas
setenv XCODE_APP_SUPPORT_DIR /Library/Application Support/Apple/Developer
Tools
setenv YACC /usr/bin/yacc
/bin/sh
-c /Users/roebel/tmp/svp_basic_transformer/build/CMakeTmp/./CMAKE_T
RY_COMPILE.build/Debug/XCODE_DEPEND_HELPER.build/Script-6859806859806859800
0.sh
/bin/sh: /Users/roebel/tmp/svp_basic_transformer/build/CMakeTmp/./CMAKE_TRY_COM
PILE.build/Debug/XCODE_DEPEND_HELPER.build/Script-68598068598068598000.sh:
/bin/sh: bad interpreter: Text file busy
** BUILD FAILED **
All configuration tests therefore have more or less random values, because
they fail either due to the fact that the tested condition is false or because
the compiler fails completely. The systems I am working with are dual
processor machines and I suppose that has something to do with these errors.
cmake is version 2.2.3. Are there any known solutions?
The third problem is probably my missing understanding. I wanted to
overwrite the configuration types, however,
SET(CMAKE_CONFIGURATION_TYPES Release;Debug CACHE STRING Configuration
types FORCE)
did not change the value of CMAKE_CONFIGURATION_TYPES .
Is this variable read only?
Cheers,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode generator problems
On Tuesday 02 May 2006 03:43, William A. Hoffman wrote: At 08:09 PM 5/1/2006, Axel Roebel wrote: Hello William, god news that there is a new version. I tried it instantly. My first impression was not so positive I found that it takes ages for the dependency checking. I am working with template libraries where most of the code is in include files. May be it is due to that, but with cmake 2.2.3 dependency checking was nevertheless 10 times faster. With 2.4.1 dependency checking takes longer than compiling the project. I don't think any changes were made in that area. In fact, if anything it should be faster. Did you build cmake with the same compiler/flags for 2.2.3 and 2.4.1? Also, I assume this is the not Xcode generator because that one does not do dependency checks in CMake. Yes, I started to try unix makefiles, because I use them most of the time. The other problem I had with 2.2.3 was that on macosx the shared libraries that I linked with were searched in the build directories not in the install directories. That seems to be fixed in 2.4.1. However, dependency checking is much longer. I did a direct comparison: with cmake 2.2.3 compiled with the default type , I suppose this none time /u/formes/share/bin/cmake -E cmake_depends Unix Makefiles /Users/roebel/src/svp/build241 /Users/roebel/src/svp/build241/compile/KernelBuild /Users/roebel/src/svp/build241/compile/KernelBuild/CMakeFiles/svp_kernel.dir/DependInfo.cmakereal real0m15.032s user0m10.154s sys 0m4.593s with 2.4.1 compiled with type release ( which did not improve compared to none) time /Users/roebel/src/cmake-2.4.1/bin/cmake -E cmake_depends Unix Makefiles /Users/roebel/src/svp/build241 /Users/roebel/src/svp/build241/compile/KernelBuild /Users/roebel/src/svp/build241/compile/KernelBuild/CMakeFiles/svp_kernel.dir/DependInfo.cmake real2m5.792s user0m7.613s sys 1m56.915s This is nearly 10 times longer Interestingly the user processing time is faster, however, system time has excessively increased. Note, that this has been measured on the same system which was doing nothing else but the dependency check! By the way, another problem with 2.4.1 is that the OUTPUT_NAME of SET_TARGET_PROPERTIES is no longer working (at least for unix makefiles) -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] some helper targets ?
Hi,
maybe they exist already, what I'd like to have is
-a target which forces cmake to rerun on all files, so that all cmake
files are executed again, but without the system checks
(e.g. our KDE4_AUTOMOC macro is executed only on cmake time, so it
wouldn't detect if such a special include is inserted into a source file
later on)
-a target which does the above and additionally reruns all checks
(find_foo(), try_compile(), ...)
Is this possible ?
How about
# helper target to remove cache
ADD_CUSTOM_TARGET(cmclean ${CMAKE_COMMAND} -E remove
${CMAKE_CACHEFILE_DIR}/CMakeCache.txt
${CMAKE_CACHEFILE_DIR}/CMakeFiles/CMakeSystem.cmake
${CMAKE_CACHEFILE_DIR}/CMakeFiles/CMakeCXXCompiler.cmake
${CMAKE_CACHEFILE_DIR}/CMakeFiles/CMakeCCompiler.cmake)
# helper target to remove reinit from scratch
ADD_CUSTOM_TARGET(reinit ${CMAKE_COMMAND} ${CMAKE_SOURCE_DIR})
ADD_DEPENDENCIES(reinit cmclean)
Now with this rebuild_cache would rebuild the cache
without tests and reinit will rebuild the cache from scratch.
Me too, I think this would be nice to have as default.
And those two I find usefull as well to switch
build type via the makefiles
ADD_CUSTOM_TARGET(set_debug ${CMAKE_COMMAND}
-DCMAKE_BUILD_TYPE:STRING=debug ${CMAKE_CURRENT_SOURCE_DIR})
ADD_CUSTOM_TARGET(set_release ${CMAKE_COMMAND}
-DCMAKE_BUILD_TYPE:STRING=release ${CMAKE_CURRENT_SOURCE_DIR})
By the way it would be nice if one could have a doc string for targets
because users that did not create the CMakeList.txt
don't understand the different targets that might be available.
Axel
Bye
Alex
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Email: [EMAIL PROTECTED] | Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] force c++
Axel Roebel wrote:
does anybody know how I may force the use of a c++ compiler
for source files with .c extension?
I think we worked around taht problem:
If one file has cpp suffix all files are compiled as C++ instead of C.
Thsu we added a dummy file per library.
Please correct me if I'm wrong.
Hi Jan,
sorry to say that, but you are wrong! If one file is c++
the linker will be used in c++ mode. But for compilation
all the c files are compiled using the c compiler.
My current workaround is :
in the sub directory I set
SET(CMAKE_C_COMPILER ${CMAKE_CXX_COMPILER})
which will replace the c compiler by the c++ compiler
for the sub directory only , and
SET_TARGET_PROPERTIES(f0main${DEBUGEXT} PROPERTIES LINKER_LANGUAGE CXX)
which will force to use c++ linker (what you achieved adding a fake c++
file). I am happy with that solution, however, I don't know whether it
would work for other things than the Unix Makefile Generator.
And I don't know whether the LINKER_LANGUAGE property
is official part of the API, because I found that in
the cmake sources and not in any documentation
Thanks
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-4054
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
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Email: [EMAIL PROTECTED] | Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] communicat variables from sub directories
On Thursday 06 April 2006 16:42, Brad King wrote:
Axel Roebel wrote:
Hello,
I am trying to collect source file lists from sub directories
into the main cmake cache.
The idea is that the main directory gets a collection of all source files
and header files such that it may run a doxygen whenever one of these
files has changed.
Imagine
SET(DOCFILES CACHE INTERNAL list of all files containing doc)
ADD_SUBDIRECTORY(src )
ADD_SUBDIRECTORY(include)
and in each subdir I tried various versions like
SET(DOCFILES ${DOCFILES}${LISTOFSRCS} )
or what I considered more likely to be correct
SET(DOCFILES ${DOCFILES}${LISTOFSRCS} CACHE INTERNAL list of all files
containing doc)
This gives me a correct list of files in the subdirectory
but the variable in the main directory is not changed.
For now I found that I need to create a new cache variable in the
sub directories to be able to read the content of that variable in the
main directory so that's what I do now.
Does anybody know how to make that work with a more elegant
solution ?
See bin/cmake --help-command GET_DIRECTORY_PROPERTY.
GET_DIRECTORY_PROPERTY(
subdir_SOMEVAR DIRECTORY subdir DEFINITION SOMEVAR
)
Thanks Brad,
this is really much nicer.
Axel
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Email: [EMAIL PROTECTED] | Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] communicat variables from sub directories
On Thursday 06 April 2006 18:00, James Bigler wrote:
Brad King wrote:
Axel Roebel wrote:
Hello,
I am trying to collect source file lists from sub directories
into the main cmake cache.
The idea is that the main directory gets a collection of all source
files and header files such that it may run a doxygen whenever one of
these files has changed.
Imagine
SET(DOCFILES CACHE INTERNAL list of all files containing doc)
ADD_SUBDIRECTORY(src )
ADD_SUBDIRECTORY(include)
and in each subdir I tried various versions like
SET(DOCFILES ${DOCFILES}${LISTOFSRCS} )
or what I considered more likely to be correct
SET(DOCFILES ${DOCFILES}${LISTOFSRCS} CACHE INTERNAL list of all
files containing doc)
This gives me a correct list of files in the subdirectory
but the variable in the main directory is not changed.
For now I found that I need to create a new cache variable in the
sub directories to be able to read the content of that variable in the
main directory so that's what I do now.
Does anybody know how to make that work with a more elegant
solution ?
See bin/cmake --help-command GET_DIRECTORY_PROPERTY.
GET_DIRECTORY_PROPERTY(
subdir_SOMEVAR DIRECTORY subdir DEFINITION SOMEVAR
)
What I've done is to use the INCLUDE() function. This will work with older
versions of CMake that don't have the newer GET_DIRECTORY_PROPERTY
functionality.
INCLUDE(subdir/CMakeLists.txt) or
INCLUDE(subdir/sources.cmake)
Inside these directories paths are relative to the CMakeLists.txt file that
included it.
sources.cmake :
SET(MY_SOURCES
subdir/Source.cc
subdir/Source2.cc
subdir/Source3.cc
)
Thanks James,
for the moment I am assuming the last version.
BTW, I always store all files with complete path, this avoids all problems
with relative paths.
Cheers,
James
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Email: [EMAIL PROTECTED] | Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] communicat variables from sub directories
Hello,
I am trying to collect source file lists from sub directories
into the main cmake cache.
The idea is that the main directory gets a collection of all source files and
header files such that it may run a doxygen whenever one of these files has
changed.
Imagine
SET(DOCFILES CACHE INTERNAL list of all files containing doc)
ADD_SUBDIRECTORY(src )
ADD_SUBDIRECTORY(include)
and in each subdir I tried various versions like
SET(DOCFILES ${DOCFILES}${LISTOFSRCS} )
or what I considered more likely to be correct
SET(DOCFILES ${DOCFILES}${LISTOFSRCS} CACHE INTERNAL list of all files
containing doc)
This gives me a correct list of files in the subdirectory
but the variable in the main directory is not changed.
For now I found that I need to create a new cache variable in the
sub directories to be able to read the content of that variable in the main
directory so that's what I do now.
Does anybody know how to make that work with a more elegant
solution ?
Thanks for any comments.
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Email: [EMAIL PROTECTED] | Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE_INIT ...
On Wednesday 05 April 2006 14:19, Eric BOIX wrote:
Dear Brad King,
Quoting Brad King [EMAIL PROTECTED]:
To get options in the GUI they need to be cache settings. Use the CACHE
form of the SET command.
IF(NOT CMAKE_BUILD_TYPE)
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING
Build Configuration)
ENDIF(NOT CMAKE_BUILD_TYPE)
I had to add the FORCE flag in order to see the result appear in the GUIs.
I hope this is ok ?
I had in fact the same problem as you. I would like to have a default
CMAKE_INSTALL_PREFIX
different of /usr/local.
so the NOT test above will not work because CMAKE_INSTALL_PREFIX is never
empty. Therefore, I test for the existance of CMakeCache.txt and FORCE the
new default value if this file does not exist.
The unfortunate side effect is that I cannot override the default value by
means of command line arguments.
Would there be a better way to change default values?
Note, that I don't want -C to be used because I want the proper default values
to be used in the make rebuild_cache target!
I wonder whether it would not be much easier of cmake would take into account
a default values file like ${CMAKE_SOURCE_DIR}/CMakeDefaults.cmake
which would be used (if it exists) to set default values much like the -C
command line option.
Kind regards,
May I abuse and ask again about some hints on the *_INIT cmake variables
(e.g. CMAKE_CXX_FLAGS_DEBUG_INIT ) and their proper usage ?
Respectfuly yours,
Eric Boix.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Axel Roebel
IRCAM Analysis/Synthesis Team
Email: [EMAIL PROTECTED] | Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
