Re: [CMake] CHECK_FUNCTION_EXISTS and -Werror
On Fri, Dec 5, 2008 at 12:27 PM, Mathieu Malaterre [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 12:12 PM, Eric Noulard [EMAIL PROTECTED] wrote: 2008/12/5 Mathieu Malaterre [EMAIL PROTECTED]: 'lo there, I had my CFLAGS set to -Werror, and because of that a try compile failed with: [...] /usr/share/cmake-2.6/Modules/CheckFunctionExists.c:3: warning: conflicting types for built-in function 'strncasecmp' Does this means strncasecmp is some kinf of function known by the gcc compiler ? It should comes from #include string.h and not from gcc itself but I may be wrong... Ok that's a builtin function since gcc 4.1 (at least). http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html Would it make sense to prepend: -fno-builtin when gcc is detected ? Thanks -- Mathieu Ref: -fno-builtin -fno-builtin-function Don't recognize built-in functions that do not begin with __builtin_ as prefix. GCC normally generates special code to handle certain built-in functions more efficiently; for instance, calls to alloca may become single instructions that adjust the stack directly, and calls to memcpy may become inline copy loops. The resulting code is often both smaller and faster, but since the function calls no longer appear as such, you cannot set a breakpoint on those calls, nor can you change the behavior of the functions by linking with a different library. In addition, when a function is recognized as a built-in function, GCC may use information about that function to warn about problems with calls to that function, or to generate more efficient code, even if the resulting code still contains calls to that function. For example, warnings are given with -Wformat for bad calls to printf, when printf is built in, and strlen is known not to modify global memory. With the -fno-builtin-function option only the built-in function function is disabled. function must not begin with __builtin_. If a function is named this is not built-in in this version of GCC, this option is ignored. There is no corresponding -fbuiltin-function option; if you wish to enable built-in functions selectively when using -fno-builtin or -ffreestanding, you may define macros such as: #define abs(n) __builtin_abs ((n)) #define strcpy(d, s)__builtin_strcpy ((d), (s)) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_FUNCTION_EXISTS and -Werror
On Sat, Dec 6, 2008 at 11:20 AM, Mathieu Malaterre [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 12:27 PM, Mathieu Malaterre [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 12:12 PM, Eric Noulard [EMAIL PROTECTED] wrote: 2008/12/5 Mathieu Malaterre [EMAIL PROTECTED]: 'lo there, I had my CFLAGS set to -Werror, and because of that a try compile failed with: [...] /usr/share/cmake-2.6/Modules/CheckFunctionExists.c:3: warning: conflicting types for built-in function 'strncasecmp' Does this means strncasecmp is some kinf of function known by the gcc compiler ? It should comes from #include string.h and not from gcc itself but I may be wrong... Ok that's a builtin function since gcc 4.1 (at least). http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html Would it make sense to prepend: -fno-builtin when gcc is detected ? Thanks -- Mathieu Ref: -fno-builtin -fno-builtin-function Don't recognize built-in functions that do not begin with __builtin_ as prefix. GCC normally generates special code to handle certain built-in functions more efficiently; for instance, calls to alloca may become single instructions that adjust the stack directly, and calls to memcpy may become inline copy loops. The resulting code is often both smaller and faster, but since the function calls no longer appear as such, you cannot set a breakpoint on those calls, nor can you change the behavior of the functions by linking with a different library. In addition, when a function is recognized as a built-in function, GCC may use information about that function to warn about problems with calls to that function, or to generate more efficient code, even if the resulting code still contains calls to that function. For example, warnings are given with -Wformat for bad calls to printf, when printf is built in, and strlen is known not to modify global memory. With the -fno-builtin-function option only the built-in function function is disabled. function must not begin with __builtin_. If a function is named this is not built-in in this version of GCC, this option is ignored. There is no corresponding -fbuiltin-function option; if you wish to enable built-in functions selectively when using -fno-builtin or -ffreestanding, you may define macros such as: #define abs(n) __builtin_abs ((n)) #define strcpy(d, s)__builtin_strcpy ((d), (s)) Logged: http://cmake.org/Bug/view.php?id=8246 Thx -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] post build add_test
Hello Is it somehow possible to make the ADD_TEST command dependent on a target? Is it possible to add tests to a project after a certain target has been built? Currently, I have the impression that tests can only be added to a project when the cmake code is executed, before the build process starts not later. But maybe, there is a trick to add tests after the buid process. I have the situation that I wanna use an executable of my own project to compute the test cases (the executable is built out of external sources that are not tested in my project). The result of the executable is a list of strings that I wanna use to add tests to my project. David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why does dependency scanning in version 2.6 seem so slow?
Senanu Pearson wrote: Is there a way to speed up the dependency scan in version 2.6? As my cmake projects became larger I noticed that dependency scanning became a much larger percentage of my build time. My project used a pre-compiled header, which included parts of boost, Qt, and stl. This caused cmake's dependency scanning to consider every object file to include everything in the PCH. My depends.make grew to be about 10 MB each for all ten or so sub-projects in my greater project. The fix was to use INCLUDE_REGULAR_EXPRESSION to block headers that are not going to change from dependency scanning. Unfortunately you need to come up with a regex that matches only files you want to do dependency scanning on. I could never think of one that would work, so instead I made some changes to my copy of cmake. I decided that what I really wanted to do is exclude everything from dependency scanning that is included using angle brackets, and I added an additional argument to INCLUDE_REGULAR_EXPRESSION that would do this. Once I stopped following includes, my build times on a full rebuild decreased from about 10 minutes to 8 and the build time of building on an unmodified source tree dropped from 1m20s to about 20s. This is something I have meaning to put in as a feature request for along time, but just haven't had time. I should mention that I did this all when using 2.4 and I haven't noticed any speed difference with 2.6 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CxxTest failure out running unit tests
On Sat, Dec 6, 2008 at 7:22 PM, Tron Thomas [EMAIL PROTECTED] wrote: I am creating a CMake configured project that uses the CxxTest unit testing framework for testing various components. When I build the test target that runs the test, and there are failures, CTest will report that the test fail, and it doesn't provide the details about what the failures were. How can I configure my test target so that it will produce the output from CxxTest that explains why certain tests failed? Use the -V flag (verbosity) to see the output of a failed test. You can also use this in conjunction with the other flags to limit the tests preformed (see -E for example). Also, if you haven't found it already, this may be of interest: http://public.kitware.com/Bug/view.php?id=6401 -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CxxTest failure out running unit tests
I know that if I type ctest -V from the command line, I can get output that include the CxxTest information. I'm not sure what I'm supposed to do in my CMakeLists.txt files that will cause the same behaviour when I build the target that runs the unit tests. Philip Lowman wrote: On Sat, Dec 6, 2008 at 7:22 PM, Tron Thomas [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I am creating a CMake configured project that uses the CxxTest unit testing framework for testing various components. When I build the test target that runs the test, and there are failures, CTest will report that the test fail, and it doesn't provide the details about what the failures were. How can I configure my test target so that it will produce the output from CxxTest that explains why certain tests failed? Use the -V flag (verbosity) to see the output of a failed test. You can also use this in conjunction with the other flags to limit the tests preformed (see -E for example). Also, if you haven't found it already, this may be of interest: http://public.kitware.com/Bug/view.php?id=6401 -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Question about install()
Hi, I have a couple of DLL files I want to copy to my executable's directory as a post-build event in the CMake-generated visual studio project files. I know I have to use install() for this, however I'm not sure how I can tell install() to copy these DLL files to the directory containing the compiled EXE file. I can't seem to find a CMAKE variable that represents the containing directory of this EXE file. Note I'm building out of source. Thanks. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CxxTest failure out running unit tests
Yes, that it what I want. Who knows of any way this might be done? Philip Lowman wrote: On Sat, Dec 6, 2008 at 9:00 PM, Tron Thomas [EMAIL PROTECTED] wrote: I know that if I type ctest -V from the command line, I can get output that include the CxxTest information. I'm not sure what I'm supposed to do in my CMakeLists.txt files that will cause the same behaviour when I build the target that runs the unit tests. So what you're asking is if there is a way to have "make test" output the equivalent of "ctest -V" on any failed tests? I don't know if that's possible out of the box, but that sounds like a useful feature to me. -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to deal with make uninstall ?
Hello, I'm a newbie of cmake. In a simple project, I worte the CMakelists.txt file like this: cmake_minimum_required(VERSION 2.6) PROJECT(FREERECITE) ADD_SUBDIRECTORY(src) ADD_SUBDIRECTORY(dict) INSTALL(FILES ../bin/FreeRecite-core DESTINATION bin) INSTALL(FILES COPYRIGHT README DESTINATION share/doc/FreeRecite) INSTALL(DIRECTORY dict/ DESTINATION share) ;;; When I use make install, everything do as I wanted. But I can't use make uninstall. How to deal with it? And I hope you can give me more links about cmake tutorial. Thanks. Kermit ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
