[cmake-developers] [CMake 0013160]: try_compile leaves temporary directories
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13160 == Reported By:Andreas Roth Assigned To: == Project:CMake Issue ID: 13160 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-04-23 03:28 EDT Last Modified: 2012-04-23 03:28 EDT == Summary:try_compile leaves temporary directories Description: I installed the version 2.8.8 of CMake and i noticed that each try_compile run leaves a directory like build\CMakeFiles\CMakeTmp\cmTryCompileExec78340897.dir. This behavior has been introduced to fix the issue described here: http://public.kitware.com/Bug/view.php?id=12957 On a build machine i noticed that each CMake run gets slower and slower. After deleting all directories in build\CMakeFiles\CMakeTmp the speed got back to normal. I used the process monitor (from sysinternals) and saw that CMake enumerates all items in the build\CMakeFiles\CMakeTmp quite often. I don't know why, but i think that's the reason for the decreasing speed. Steps to Reproduce: 1. delete the CMakeCache.txt file if it exists 2. Run cmake -G Visual Studio 9 2008 . with CMakeLists.txt: PROJECT(HelloWorld C CXX) this detects the compiler and leaves several directories in CMakeFiles\CMakeTmp. 3. goto step 1 == Issue History Date ModifiedUsername FieldChange == 2012-04-23 03:28 Andreas Roth New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja bug
On Mon, Apr 23, 2012 at 3:52 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 4/21/2012 7:37 AM, Peter Kümmel wrote: Great! Is this the step which will be dropped when the /fast target is build? Peter No, that drops building all the dependent targets. So, would it be possible to use CMake's depend generation with ninja? Right now ninja creates the .d files as part of the compilation. Is it possible to move that to a separate pass? Is it possible to have a per target .d file? This is actually important for Fortran support, which right now is totally broken in ninja. For Fortran, you have to parse all the files first to find out what order they need to be compiled in. So, doing it on the compile line is too late. Bill, A short answer, because it is topic that will require more work in the generator and I have to think more about it. I don't think it is trivial. The depfile attribute for a rule is not mandatory. So, yes I think it is possible to use the CMake's depend generation with Ninja as a fallback. Actually, that was one of the question I had in mind when I started to work on this generator. When Peter picked up the torch, he went straight to the usual depfile as it is done in Ninja itself. For the per target .d file, I think it is possible too. It is close the request to have .s and .i target for each built files. I add that to my todo list but it is growing faster than I removed items. Spare time... Maybe Peter has an idea about how to implement this quickly. Cheers, -- Nicolas Desprès -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013161]: Java support can violate the command-line string limitation
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13161 == Reported By:Frank Glinka Assigned To: == Project:CMake Issue ID: 13161 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-04-23 13:28 EDT Last Modified: 2012-04-23 13:28 EDT == Summary:Java support can violate the command-line string limitation Description: Currently, the add_jar function composes a single command-line expression which invokes javac and passes all java files as command-line arguments. As soon as the number of Java files gets bigger and/or the files are placed in folders with long path names, the system limit for command-line expressions is easily reached. Steps to Reproduce: Create a medium-sized java project with long path names to the Java files. Additional Information: The Java compiler allows to provide a file as a program argument which lists the source files to be compiled. This might be the better choice: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html == Issue History Date ModifiedUsername FieldChange == 2012-04-23 13:28 Frank Glinka New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013162]: create_symlink command portability
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13162 == Reported By:Dave Abrahams Assigned To: == Project:CMake Issue ID: 13162 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-04-24 01:22 EDT Last Modified: 2012-04-24 01:22 EDT == Summary:create_symlink command portability Description: This command could be made to work on many-many Windows systems these days. Bonus: if symlinking not available, copy files instead. == Issue History Date ModifiedUsername FieldChange == 2012-04-24 01:22 Dave Abrahams New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] cmake 32/64 bit
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application. As a
consequence, it has only access to the 32 bit registry entries (WOW64). I
have installed python as a 64 bit application, which is not listed in the
32 bit registry.
By accessing
HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath
in the FinPythonLibs.cmake as the path, the 32 bit cmake does not find a
python installation. Unfortunately, there is also no possibility to set the
variables (PYTHON_LIBRARY PYTHON_INCUDE_DIR) manually. If I manually add in
the 32 bit registry the 64 bit application (python), everything works,
though this is just something I did to locate the problem, not a permanent
solution.
Any ideas how to circumvent these problems? Or is there a way to build a 64
bit cmake?
Jörg F.
--
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] cmake 32/64 bit
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application. As a
consequence, it has only access to the 32 bit registry entries (WOW64). I
have installed python as a 64 bit application, which is not listed in the
32 bit registry.
By accessing
HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath
in the FinPythonLibs.cmake as the path, the 32 bit cmake does not find a
python installation. Unfortunately, there is also no possibility to set
the
variables (PYTHON_LIBRARY PYTHON_INCUDE_DIR) manually. If I manually add
in
the 32 bit registry the 64 bit application (python), everything works,
though this is just something I did to locate the problem, not a permanent
solution.
Any ideas how to circumvent these problems? Or is there a way to build a
64
bit cmake?
If you call cmake in the build tree as cmake -D
PYTHON_LIBRARY=f:/foo/bar/mypython.lib -D
PYTHON_INCLUDE_DIR=f:/foo/bar/include . this should work.
Eike
--
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
[CMake] target_link_libraries can't link shared libraries not listed in LD_LIBRARY_PATH
Hi All!
I have a problem with target_link_libraries. It can't link with shared
libraries not from directory listed in LD_LIBRARY_PATH.
1. When I try to link shared library with the full path obtained from
find_library, my library is passed to gcc without -l option as ordinary
object file.
2. When I try to link by specifying short name cblas I've got the
error message:
Linking CXX shared library ../../sndcompare/amd64sse3/libsndcompared.so
/usr/bin/ld: cannot find -lcblas
collect2: ld returned 1 exit status
make[2]: *** [../../sndcompare/amd64sse3/libsndcompared.so] Error 1
make[1]: *** [CMakeFiles/sndcompare.dir/all] Error 2
make: *** [all] Error 2
*** Failed ***
OS: Ubuntu 11.10 64 bit
Compiler: g++ 4.6.1.
Cmake 2.8.5
add_library(${lib_name} SHARED
${io_files}
${utils_files}
${tech_independ_files}
${other_files}
)
find_library(atlas
NAME atlas
PATHS
${CMAKE_CURRENT_SOURCE_DIR}/${CMAKE_SYSTEM_NAME}/atlas/${arch}/lib
DOC Atlas library
)
find_library(cblas
NAME cblas
PATHS
${CMAKE_CURRENT_SOURCE_DIR}/${CMAKE_SYSTEM_NAME}/atlas/${arch}/lib
DOC Cblas library
)
link_directories(
${CMAKE_CURRENT_SOURCE_DIR}/${CMAKE_SYSTEM_NAME}/atlas/${arch}/lib
${CMAKE_CURRENT_SOURCE_DIR}/../../Sphinx/sphinxbase/${CMAKE_SYSTEM_NAME}/${arch}/lib
)
target_link_libraries(${lib_name}
debug ${do_scoring_debug}
optimized ${do_scoring}
general ${spinx}
general rt
general dl
general pthread
general cblas
general ${atlas}
)
Thank you in advance, Vyacheslav.
--
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] cpack and paths too long
On 04/20/2012 12:36 PM, Eric Noulard wrote: Nope, it would break backward compatibility, you can dig the ML for discussion about that issue. My opinion is that building in-source is a bad habit that ought to be discouraged but the fact is, this is not currently easy to enforce out-of-source: http://www.cmake.org/Bug/view.php?id=6672 Ok the make problem was my mistake sorry.. we haven't really solved the long path problem yet unfortunately, even building out of source we get some very long paths... Is there a way to shorten this generated path by CPack? C:/Temp/cmake_gen/_CPack_Packages/win32/NSIS* * Anyway the only solution I see for now is to check with a script the length of the paths, and abort before trying to build anything. Or the other possible solution is to run cpack from an OS which is not embarrassing, but not sure what version of CMake we have available and if the NSIS is working fine on that version.. -- 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] cpack and paths too long
You should just get used to using shorter paths on the embarrassing OS. This is an early warning sign for you that your end users will also encounter these problems as they install your program on their systems in non-short root paths... You can ignore it if you wish, but the fact remains that Windows STILL has many components in it that rely on full path names of ALL files being less than 260 characters. They do support longer file names, but there are still many legacy tools where the limit exists. HTH, David On Mon, Apr 23, 2012 at 8:26 AM, Andrea Crotti andrea.crott...@gmail.comwrote: On 04/20/2012 12:36 PM, Eric Noulard wrote: Nope, it would break backward compatibility, you can dig the ML for discussion about that issue. My opinion is that building in-source is a bad habit that ought to be discouraged but the fact is, this is not currently easy to enforce out-of-source:http://www.cmake.org/Bug/view.php?id=6672 Ok the make problem was my mistake sorry.. we haven't really solved the long path problem yet unfortunately, even building out of source we get some very long paths... Is there a way to shorten this generated path by CPack? C:/Temp/cmake_gen/_CPack_Packages/win32/NSIS* * Anyway the only solution I see for now is to check with a script the length of the paths, and abort before trying to build anything. Or the other possible solution is to run cpack from an OS which is not embarrassing, but not sure what version of CMake we have available and if the NSIS is working fine on that version.. -- 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 -- 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] cpack and paths too long
On 04/23/2012 01:32 PM, David Cole wrote: You should just get used to using shorter paths on the embarrassing OS. This is an early warning sign for you that your end users will also encounter these problems as they install your program on their systems in non-short root paths... You can ignore it if you wish, but the fact remains that Windows STILL has many components in it that rely on full path names of ALL files being less than 260 characters. They do support longer file names, but there are still many legacy tools where the limit exists. HTH, David I agree with you, unfortunately I'm not the person that has to use smaller paths, just writing the build system.. And good point about the installed application, I think I can assume however that if the CPack works also the installed application should work, because it doesn't have the ~20 chars needed for CPacking (but of course depends on where it will be installed). So well the only way is to make really sure there are no long paths around then :( -- 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] cmake 32/64 bit
Am 23.04.2012 10:45, schrieb Jörg F. Unger: Hi everyone, ... Any ideas how to circumvent these problems? Or is there a way to build a 64 bit cmake? You can build 64 bit cmake with the 32 bit version and at least the mingw-w64 compiler, it probably builds using visual studio too. I haven't tested yet if solves your problem though... Jörg F. regards, Patrick -- 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] target_link_libraries can't link shared libraries not listed in LD_LIBRARY_PATH
Hi,
On Mon, Apr 23, 2012 at 13:24, Vyacheslav Karamov ubuntul...@yandex.ruwrote:
Hi All!
I have a problem with target_link_libraries. It can't link with shared
libraries not from directory listed in LD_LIBRARY_PATH.
1. When I try to link shared library with the full path obtained from
find_library, my library is passed to gcc without -l option as ordinary
object file.
What is the problem with linking the absolute path of the shared library?
This should just work
2. When I try to link by specifying short name cblas I've got the error
message:
Linking CXX shared library ../../sndcompare/amd64sse3/**libsndcompared.so
/usr/bin/ld: cannot find -lcblas
collect2: ld returned 1 exit status
make[2]: *** [../../sndcompare/amd64sse3/**libsndcompared.so] Error 1
make[1]: *** [CMakeFiles/sndcompare.dir/**all] Error 2
make: *** [all] Error 2
*** Failed ***
This is because the linker does not know the directory where to search for
the library.
add_library(${lib_name} SHARED
${io_files}
${utils_files}
${tech_independ_files}
${other_files}
)
find_library(atlas
NAME atlas
PATHS ${CMAKE_CURRENT_SOURCE_DIR}/${**CMAKE_SYSTEM_NAME}/atlas/${**
arch}/lib
DOC Atlas library
)
find_library(cblas
NAME cblas
PATHS ${CMAKE_CURRENT_SOURCE_DIR}/${**CMAKE_SYSTEM_NAME}/atlas/${**
arch}/lib
DOC Cblas library
)
link_directories(
${CMAKE_CURRENT_SOURCE_DIR}/${**CMAKE_SYSTEM_NAME}/atlas/${**arch}/lib
${CMAKE_CURRENT_SOURCE_DIR}/..**/../Sphinx/sphinxbase/${CMAKE_**
SYSTEM_NAME}/${arch}/lib
)
link_directories is not needed at all here or should not be needed. Just
make sure to pass ${cblas} and ${atlas} to
target_link_libraries. If that produces errors please provide the exact
error message.
Andreas
--
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] target_link_libraries can't link shared libraries not listed in LD_LIBRARY_PATH
Hi!
I just find the solution. The problem was in order how libraries were
specified.
target_link_libraries(${lib_name}
general rt
general dl
general pthread
debug ${do_scoring_debug}
optimized ${do_scoring}
general ${spinx}
general ${cblas}
general ${atlas}
)
23.04.2012 16:28, Andreas Pakulat ???:
Hi,
On Mon, Apr 23, 2012 at 13:24, Vyacheslav Karamov
ubuntul...@yandex.ru mailto:ubuntul...@yandex.ru wrote:
Hi All!
I have a problem with target_link_libraries. It can't link with
shared libraries not from directory listed in LD_LIBRARY_PATH.
1. When I try to link shared library with the full path obtained
from find_library, my library is passed to gcc without -l option
as ordinary object file.
What is the problem with linking the absolute path of the shared
library? This should just work
2. When I try to link by specifying short name cblas I've got
the error message:
Linking CXX shared library
../../sndcompare/amd64sse3/libsndcompared.so
/usr/bin/ld: cannot find -lcblas
collect2: ld returned 1 exit status
make[2]: *** [../../sndcompare/amd64sse3/libsndcompared.so] Error 1
make[1]: *** [CMakeFiles/sndcompare.dir/all] Error 2
make: *** [all] Error 2
*** Failed ***
This is because the linker does not know the directory where to search
for the library.
add_library(${lib_name} SHARED
${io_files}
${utils_files}
${tech_independ_files}
${other_files}
)
find_library(atlas
NAME atlas
PATHS
${CMAKE_CURRENT_SOURCE_DIR}/${CMAKE_SYSTEM_NAME}/atlas/${arch}/lib
DOC Atlas library
)
find_library(cblas
NAME cblas
PATHS
${CMAKE_CURRENT_SOURCE_DIR}/${CMAKE_SYSTEM_NAME}/atlas/${arch}/lib
DOC Cblas library
)
link_directories(
${CMAKE_CURRENT_SOURCE_DIR}/${CMAKE_SYSTEM_NAME}/atlas/${arch}/lib
${CMAKE_CURRENT_SOURCE_DIR}/../../Sphinx/sphinxbase/${CMAKE_SYSTEM_NAME}/${arch}/lib
)
link_directories is not needed at all here or should not be needed.
Just make sure to pass ${cblas} and ${atlas} to
target_link_libraries. If that produces errors please provide the
exact error message.
Andreas
--
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] cmake 32/64 bit
On Mon, Apr 23, 2012 at 4:45 AM, Jörg F. Unger
joergfun...@googlemail.com wrote:
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application. As a
consequence, it has only access to the 32 bit registry entries (WOW64). I
have installed python as a 64 bit application, which is not listed in the 32
bit registry.
By accessing
HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath
in the FinPythonLibs.cmake as the path, the 32 bit cmake does not find a
python installation. Unfortunately, there is also no possibility to set the
variables (PYTHON_LIBRARY PYTHON_INCUDE_DIR) manually. If I manually add in
the 32 bit registry the 64 bit application (python), everything works,
though this is just something I did to locate the problem, not a permanent
solution.
Any ideas how to circumvent these problems? Or is there a way to build a 64
bit cmake?
At the point when you call find_package(PythonLibs) make sure you have
at least one language enabled. That way CMake knows the address size
of the toolchain's target format. That is important when searching so
CMake knows which registry view to use:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v2.8.8#l381
Note that the PlatformIs64Bit test is here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v2.8.8#l2195
-Brad
--
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] target_link_libraries can't link shared libraries not listed in LD_LIBRARY_PATH
Hi!
I just find the solution. The problem was in order how libraries were
specified.
target_link_libraries(${lib_name}
general rt
general dl
general pthread
debug ${do_scoring_debug}
optimized ${do_scoring}
general ${spinx}
general ${cblas}
general ${atlas}
)
You don't need the general keyword, specifying just a library will make it
be used with any build type.
Also you may want to replace general dl with ${CMAKE_DL_LIBS} and
general pthread with ${CMAKE_THREAD_LIBS_INIT} for portability. Note
that you need find_package(Threads) for the latter to work.
Eike
--
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] cmake 32/64 bit
2012/4/23 Brad King brad.k...@kitware.com
On Mon, Apr 23, 2012 at 4:45 AM, Jörg F. Unger
joergfun...@googlemail.com wrote:
Hi everyone,
I'm using windows 7 (64). I'm trying to determine the python installation
using cmake.
The problem is that cmake only exists as a 32 bit application. As a
consequence, it has only access to the 32 bit registry entries (WOW64). I
have installed python as a 64 bit application, which is not listed in
the 32
bit registry.
By accessing
HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath
in the FinPythonLibs.cmake as the path, the 32 bit cmake does not find a
python installation. Unfortunately, there is also no possibility to set
the
variables (PYTHON_LIBRARY PYTHON_INCUDE_DIR) manually. If I manually add
in
the 32 bit registry the 64 bit application (python), everything works,
though this is just something I did to locate the problem, not a
permanent
solution.
Any ideas how to circumvent these problems? Or is there a way to build a
64
bit cmake?
At the point when you call find_package(PythonLibs) make sure you have
at least one language enabled. That way CMake knows the address size
of the toolchain's target format. That is important when searching so
CMake knows which registry view to use:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v2.8.8#l381
Note that the PlatformIs64Bit test is here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v2.8.8#l2195
-Brad
I've tried to test this using
PROJECT(NuTo CXX C Fortran)
MESSAGE(STATUS CMAKE_SIZEOF_VOID_P ${CMAKE_SIZEOF_VOID_P})
which gives 4. The problem is that I installed the 32bit version of MinGW.
--
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] cpack and paths too long
On Mon, Apr 23, 2012 at 8:38 AM, Andrea Crotti andrea.crott...@gmail.comwrote: On 04/23/2012 01:32 PM, David Cole wrote: You should just get used to using shorter paths on the embarrassing OS. This is an early warning sign for you that your end users will also encounter these problems as they install your program on their systems in non-short root paths... You can ignore it if you wish, but the fact remains that Windows STILL has many components in it that rely on full path names of ALL files being less than 260 characters. They do support longer file names, but there are still many legacy tools where the limit exists. HTH, David I agree with you, unfortunately I'm not the person that has to use smaller paths, just writing the build system.. And good point about the installed application, I think I can assume however that if the CPack works also the installed application should work, because it doesn't have the ~20 chars needed for CPacking (but of course depends on where it will be installed). So well the only way is to make really sure there are no long paths around then :( If Windows is your target system, then yes: you must make sure all your paths are short enough. Cheers, David -- 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
[CMake] Autotools sub project, static lib in a shared lib
Hi, I have a cmake project with some weird requirements: It uses an external project that uses autotools. I have the other project's source tree unpacked in a subdirectory. During a build of my project, I want to run configure with some options, make, and make install in the subdirectory, then copy a static library out of the install dir, and link that into a shared library my project builds. In make, I'd write rules roughly like this: lib/libext.a: ext/configure (cd ext; ./configure --prefix=$(PWD)/extbuild; make; make install; install extbuild/lib/libext.a lib) lib/libproj.so: $(objs) lib/libext.a cc -o $@ -shared $^ How should I do this in cmake? Does the IMPORTED property of add_library help me at all? Sent from my iPhone -- 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] Wiki: version compatibility matrix
Hi David, Yes, I should have time somewhere this week... Johannes On Thursday, April 19, 2012 11:20:48 PM David Cole wrote: Hi Johannes, Time to update again, this time for CMake 2.8.8. Do you have time to do the update again in the next week or two? Thanks, David On Thu, Jan 5, 2012 at 4:47 PM, Johannes Zarl johannes.z...@jku.at wrote: Hi David, This is great news! I have updated the matrix to use footnotes, and also added the 2.8.7 changes to it. The whole matrix now looks much more clearly: http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix Cheers, Johannes On Tuesday 03 January 2012 17:25:31 David Cole wrote: The Cite extension is now installed on the CMake wiki. See this page to see what mediawiki extensions are available: http://www.cmake.org/Wiki/Special:Version -- 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 -- 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
[CMake] Ctest memcheck trickery
Hi, Another question: I want to be able to run my tests with and without valgrind. A few tests should always run without valgrind, and a few others should run with helgrind and still others with drd. Currently, I have a function add_memcheck_test that invokes add_test twice and creates targets foo_test and memcheck_foo_test (and similar for helgrind and drd). So most tests use that, and a few that shouldn't use valgrind at all just use add_test. So I can run ctest -R memcheck or ctest -E memcheck to decide whether to use valgrind or not. But this seems like not the cmake way. I feel like I should be instead running ctest -D Experimental or ctest -D ExperimentalMemCheck. Is there a way to use these but still be able to disable valgrind for a few tests and to change the options (--tool=helgrind for example) for a few others? Something like set properties on those tests, to set CMAKE_MEMORYCHECK_COMMAND(_OPTIONS) or whatever it is? Sent from my iPhone -- 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] Autotools sub project, static lib in a shared lib
Hi, You can have a look at the ExternalProject module: $ cmake --help-module ExternalProject Cheers, -Nico On Mon, Apr 23, 2012 at 5:10 PM, Leif Walsh leif.wa...@gmail.com wrote: Hi, I have a cmake project with some weird requirements: It uses an external project that uses autotools. I have the other project's source tree unpacked in a subdirectory. During a build of my project, I want to run configure with some options, make, and make install in the subdirectory, then copy a static library out of the install dir, and link that into a shared library my project builds. In make, I'd write rules roughly like this: lib/libext.a: ext/configure (cd ext; ./configure --prefix=$(PWD)/extbuild; make; make install; install extbuild/lib/libext.a lib) lib/libproj.so: $(objs) lib/libext.a cc -o $@ -shared $^ How should I do this in cmake? Does the IMPORTED property of add_library help me at all? Sent from my iPhone -- 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 -- Nicolas Desprès -- 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
[CMake] Clear cache on upgrade?
I am wondering what a good rule of thumb is when upgrading CMake. Should I delete my cache after each upgrade? I'm on Windows. -- 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] Clear cache on upgrade?
On Mon, Apr 23, 2012 at 1:46 PM, Robert Dailey rcdailey.li...@gmail.com wrote: I am wondering what a good rule of thumb is when upgrading CMake. Should I delete my cache after each upgrade? I'm on Windows. -- I never ever do that on windows. And I have done 100s of builds with CMake and many upgrades since CMake 2.4. John -- 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] Clear cache on upgrade?
A good rule of thumb is to try just upgrading CMake and running it on existing build trees. It's obviously quicker than a re-configure from scratch. But then, before complaining about something not working, try it in a fresh build tree first, then if it's still wrong, complain. :-) It's rare, although it does happen sometimes, that we make a change in CMake itself that invalidates something that's in an existing cache. Obviously (or maybe not depending on who you are), some sort of automated testing, like nightly dashboards, should be doing full re-configures on a frequent basis anyhow. HTH, David On Mon, Apr 23, 2012 at 2:06 PM, John Drescher dresche...@gmail.com wrote: On Mon, Apr 23, 2012 at 1:46 PM, Robert Dailey rcdailey.li...@gmail.com wrote: I am wondering what a good rule of thumb is when upgrading CMake. Should I delete my cache after each upgrade? I'm on Windows. -- I never ever do that on windows. And I have done 100s of builds with CMake and many upgrades since CMake 2.4. John -- 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 -- 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] Clear cache on upgrade?
A good rule of thumb is to try just upgrading CMake and running it on existing build trees. It's obviously quicker than a re-configure from scratch. But then, before complaining about something not working, try it in a fresh build tree first, then if it's still wrong, complain. :-) It's rare, although it does happen sometimes, that we make a change in CMake itself that invalidates something that's in an existing cache. Fully agreed.. It has been quite rare that a CMake upgrade has caused a problem or a need to re configure. John -- 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
[CMake] Zero coverage being reported on gcc/Linux builds.
cmake: 2.8.6 gcc/g++: 4.4.6-3 Red Hate Enterprise Linux 6.2 I follow the instructions here: http://www.cmake.org/Wiki/CTest/Coverage And I have 2 different dashboards that report zero coverage: http://testing.psychiatry.uiowa.edu/CDash/index.php?project=BRAINSStandalone http://testing.psychiatry.uiowa.edu/CDash/index.php?project=ANTS I don't know what's going on because I remember coverage working, and it's obviously doing something for other projects, e.g. ITK: http://public.kitware.com/dashboard.php?name=itk Call me an idiot, but I can follow instructions, and following the instructions I can find isn't doing the trick. -- 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] Clear cache on upgrade?
On 2012-04-23 14:13-0400 David Cole wrote: A good rule of thumb is to try just upgrading CMake and running it on existing build trees. It's obviously quicker than a re-configure from scratch. But then, before complaining about something not working, try it in a fresh build tree first, then if it's still wrong, complain. :-) It's rare, although it does happen sometimes, that we make a change in CMake itself that invalidates something that's in an existing cache. Obviously (or maybe not depending on who you are), some sort of automated testing, like nightly dashboards, should be doing full re-configures on a frequent basis anyhow. Just to give a slightly different view, I do reconfigure a lot more than implied above. One reason I do it is I am often changing/updating the CMake-based build system of whatever project I am working on, and I don't think there are any guarantees that CMake will work in that case without a complete reconfigure. Furthermore, even if I am not fiddling with the CMake-based build system, I do often try new versions of software my software package depends on that is installed in a non-standard location. For that case I believe CMake just continues to rely on the cached version of what it found before unless you start updating the cached variables yourself, and I just prefer to start fresh in that case (typically with PATH, PKG_CONFIG_PATH, CMAKE_LIBRARY_PATH, and CMAKE_INCLUDE_PATH environment variables set appropriately so the new version of the required software is found in its non-standard location). So even though it is the usual case that cmake reconfiguration is not required, I think there are some obvious cases like above where it is needed as well as not-so-obvious ones as well. So I definitely endorse Dave's advice above to try a fresh build whenever some aspect of the CMake-based build and/or test system doesn't appear to be working correctly and certainly before any error is reported. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] Ignore install()
Hi Stefan,
one solution I can think about is overwriting the install() command
before you traverse into these subdirectories and restoring the
default CMake behavior afterwards, i.e., something like
# overwrite install() command with a dummy macro that is a nop
macro (install)
endmacro ()
# configure build system for external libraries
add_subdirectory(external)
# replace install macro by one which simply invokes the CMake
install() function with the given arguments
macro (install)
_install(${ARGV})
endmacro(install)
# configure build system of project own sources including installation rules
add_subdirectory(src)
Andreas
On Wed, Apr 18, 2012 at 2:12 PM, Stefan Schindler ste...@boxbox.org wrote:
Hey guys,
I wonder if it's possible to ignore install() commands in projects that
are being built using add_subdirectory().
I've got a project that builds external libraries and links statically
to them, so there's no need to install them in the final step.
A workaround is to remove the files after installing, but I'd rather go
with a cleaner solution.
Greetings,
Stefan.
--
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
--
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] Reading flags that have been added with add_definitions
Hi Mathias,
I simply guess that the reason for COMPILE_DEFINITIONS not including
-pedantic is, that you actually use add_definitions() for something
what it is not really intended for, i.e., the addition of compiler
flags other than those which define preprocessor macros... maybe
add_definitions() recognizes it as compiler flags and adds it to
either one of the variables which define the compiler flags. Check the
value of the target property COMPILE_FLAGS on one of the targets added
after the add_definitions() call.
However, you should actually add global compiler flags to the
(command-line argument) srings (not CMake lists!) CMAKE_CXX_FLAGS,
CMAKE_C_FLAGS, CMAKE_CXX_CONFIG, CMAKE_C_FLAGS_CONFIG.
set (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -pedantic)
Andreas
On Wed, Apr 18, 2012 at 10:23 AM, Mathias Gaunard
mathias.gaun...@ens-lyon.org wrote:
Is there a way to read back what flags were added with add_definitions?
If I do
add_definitions(DFOO=bar -pedantic)
when I read the COMPILE_DEFINITIONS property of the directory all I have is
FOO=bar
How can I know the -pedantic option is being used for all targets in the
directory?
--
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
--
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
[Cmake-commits] CMake branch, next, updated. v2.8.8-2669-g36ae365
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 36ae3659c2d2cf4f7917f0ab9d5eaa5a455c0b55 (commit)
via 69626f02b6901208c29931f59a8437f03fd82c3b (commit)
via 2d951c1d1a01a1d7fdd677fc0309a2f2472c6c3c (commit)
from 42d1169eaff4ec041c1393122331e8f7e763 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=36ae3659c2d2cf4f7917f0ab9d5eaa5a455c0b55
commit 36ae3659c2d2cf4f7917f0ab9d5eaa5a455c0b55
Merge: 42d1169 69626f0
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Apr 23 09:56:19 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Apr 23 09:56:19 2012 -0400
Merge topic 'module-no-soname' into next
69626f0 Test NO_SONAME property (#13155)
2d951c1 Support building shared libraries or modules without soname (#13155)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69626f02b6901208c29931f59a8437f03fd82c3b
commit 69626f02b6901208c29931f59a8437f03fd82c3b
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Apr 23 09:53:29 2012 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Apr 23 09:53:29 2012 -0400
Test NO_SONAME property (#13155)
Teach the Plugin test to check that the NO_SONAME target property works
as documented. Check that the IMPORTED targets are written with the
correct properties. When readelf is available use it to check the
actual binary files for SONAME fields.
diff --git a/Tests/Plugin/CMakeLists.txt b/Tests/Plugin/CMakeLists.txt
index b0942c0..31ca59c 100644
--- a/Tests/Plugin/CMakeLists.txt
+++ b/Tests/Plugin/CMakeLists.txt
@@ -39,6 +39,50 @@ TARGET_LINK_LIBRARIES(example_exe kwsys)
ADD_LIBRARY(example_mod_1 MODULE src/example_mod_1.c)
TARGET_LINK_LIBRARIES(example_mod_1 example_exe)
+
+IF(CMAKE_SHARED_LIBRARY_SONAME_C_FLAG AND
+${CMAKE_C_CREATE_SHARED_MODULE} MATCHES SONAME_FLAG)
+ # Add a second plugin that should not have any soname.
+ ADD_LIBRARY(example_mod_2 MODULE src/example_mod_1.c)
+ TARGET_LINK_LIBRARIES(example_mod_2 example_exe)
+ SET_PROPERTY(TARGET example_mod_2 PROPERTY NO_SONAME 1)
+
+ # Verify that targets export with proper IMPORTED SONAME properties.
+ EXPORT(TARGETS example_mod_1 example_mod_2 NAMESPACE exp_
+FILE ${CMAKE_CURRENT_BINARY_DIR}/mods.cmake)
+ INCLUDE(${CMAKE_CURRENT_BINARY_DIR}/mods.cmake)
+ GET_PROPERTY(configs TARGET exp_example_mod_1 PROPERTY
IMPORTED_CONFIGURATIONS)
+ FOREACH(c ${configs})
+STRING(TOUPPER ${c} CONFIG)
+GET_PROPERTY(soname1 TARGET exp_example_mod_1 PROPERTY
IMPORTED_SONAME_${CONFIG})
+GET_PROPERTY(soname2 TARGET exp_example_mod_2 PROPERTY
IMPORTED_NO_SONAME_${CONFIG})
+IF(soname1)
+ MESSAGE(STATUS exp_example_mod_1 has IMPORTED_SONAME_${CONFIG} as
expected: ${soname1})
+ELSE()
+ MESSAGE(SEND_ERROR exp_example_mod_1 does not have
IMPORTED_SONAME_${CONFIG} but should)
+ENDIF()
+IF(soname2)
+ MESSAGE(STATUS exp_example_mod_2 has IMPORTED_NO_SONAME_${CONFIG} as
expected: ${soname2})
+ELSE()
+ MESSAGE(SEND_ERROR exp_example_mod_2 does not have
IMPORTED_NO_SONAME_${CONFIG} but should)
+ENDIF()
+ ENDFOREACH()
+
+ # Parse the binary to check for SONAME if possible.
+ IF(${CMAKE_EXECUTABLE_FORMAT} MATCHES ELF)
+FIND_PROGRAM(READELF_EXE readelf)
+IF(READELF_EXE)
+ ADD_CUSTOM_TARGET(check_mod_soname ALL COMMAND
+${CMAKE_COMMAND} -Dreadelf=${READELF_EXE}
+ -Dmod1=$TARGET_FILE:example_mod_1
+ -Dmod2=$TARGET_FILE:example_mod_2
+-P ${CMAKE_CURRENT_SOURCE_DIR}/check_mod_soname.cmake
+)
+ ADD_DEPENDENCIES(check_mod_soname example_mod_1 example_mod_2)
+ENDIF()
+ ENDIF()
+ENDIF()
+
# TODO:
# - create a plugin that links to a static lib
# - create a plugin that links to a shared lib
diff --git a/Tests/Plugin/check_mod_soname.cmake
b/Tests/Plugin/check_mod_soname.cmake
new file mode 100644
index 000..3737b45
--- /dev/null
+++ b/Tests/Plugin/check_mod_soname.cmake
@@ -0,0 +1,14 @@
+execute_process(COMMAND ${readelf} -d ${mod1} OUTPUT_FILE ${mod1}.readelf.txt)
+execute_process(COMMAND ${readelf} -d ${mod2} OUTPUT_FILE ${mod2}.readelf.txt)
+file(STRINGS ${mod1}.readelf.txt soname1 REGEX \\(SONAME\\))
+file(STRINGS ${mod2}.readelf.txt soname2 REGEX \\(SONAME\\))
+if(soname1)
+ message(STATUS ${mod1} has soname as expected: ${soname1})
+else()
+ message(FATAL_ERROR ${mod1} has no soname but should:\n ${soname1})
+endif()
+if(soname2)
+ message(FATAL_ERROR ${mod2} has soname but should not:\n ${soname2})
+else()
+ message(STATUS ${mod2} has no soname as
[Cmake-commits] CMake branch, next, updated. v2.8.8-2671-gb9fe606
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via b9fe606aff25f7940082e60bedb0b1cd28176aaa (commit)
via 6ad39679856a5fc9a90c24923af8e48901923cb6 (commit)
from 36ae3659c2d2cf4f7917f0ab9d5eaa5a455c0b55 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b9fe606aff25f7940082e60bedb0b1cd28176aaa
commit b9fe606aff25f7940082e60bedb0b1cd28176aaa
Merge: 36ae365 6ad3967
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Apr 23 11:37:55 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Apr 23 11:37:55 2012 -0400
Merge topic 'module-no-soname' into next
6ad3967 OS X: Fix Framework install-name after NO_SONAME change
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6ad39679856a5fc9a90c24923af8e48901923cb6
commit 6ad39679856a5fc9a90c24923af8e48901923cb6
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Apr 23 11:20:12 2012 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Apr 23 11:30:13 2012 -0400
OS X: Fix Framework install-name after NO_SONAME change
Commit 2d951c1d (Support building shared libraries or modules without
soname, 2012-04-22) factored test logic out of cmTarget::GetSOName to
create cmTarget::HasSOName, but it took slightly too much of the test.
OS X frameworks do have an install-name (OS X equivalent to soname) but
do not have versioned file names. Move that piece of the test logic
back to its original location.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 05ded57..c96ca94 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -3025,8 +3025,7 @@ bool cmTarget::HasSOName(const char* config)
return ((this-GetType() == cmTarget::SHARED_LIBRARY ||
this-GetType() == cmTarget::MODULE_LIBRARY)
!this-GetPropertyAsBool(NO_SONAME)
- this-Makefile-GetDefinition(sonameFlag.c_str())
- !this-IsFrameworkOnApple());
+ this-Makefile-GetDefinition(sonameFlag.c_str()));
}
//
@@ -3365,7 +3364,8 @@ void cmTarget::GetLibraryNames(std::string name,
// Check for library version properties.
const char* version = this-GetProperty(VERSION);
const char* soversion = this-GetProperty(SOVERSION);
- if(!this-HasSOName(config))
+ if(!this-HasSOName(config) ||
+ this-IsFrameworkOnApple())
{
// Versioning is supported only for shared libraries and modules,
// and then only when the platform supports an soname flag.
---
Summary of changes:
Source/cmTarget.cxx |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.8-2674-gfc1af7e
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via fc1af7e4b79ecd4d76d78d4535fa45fc5be0fd09 (commit)
via 83729f978f02b36f7d0f1e44439450d7d61a4aa6 (commit)
via 5b97942cbb915e8eaff0b5b9fee0676296656c93 (commit)
from b9fe606aff25f7940082e60bedb0b1cd28176aaa (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc1af7e4b79ecd4d76d78d4535fa45fc5be0fd09
commit fc1af7e4b79ecd4d76d78d4535fa45fc5be0fd09
Merge: b9fe606 83729f9
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Mon Apr 23 14:52:42 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Apr 23 14:52:42 2012 -0400
Merge topic 'EnhanceBash-completion-part1' into next
83729f9 Install editors helper files
5b97942 Enhancement of bash completion scripts given by Igor Murzov.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83729f978f02b36f7d0f1e44439450d7d61a4aa6
commit 83729f978f02b36f7d0f1e44439450d7d61a4aa6
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Mon Apr 23 20:48:17 2012 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Mon Apr 23 20:49:33 2012 +0200
Install editors helper files
diff --git a/Docs/CMakeLists.txt b/Docs/CMakeLists.txt
index 0848fef..b04b32d 100644
--- a/Docs/CMakeLists.txt
+++ b/Docs/CMakeLists.txt
@@ -1,2 +1,4 @@
string(REGEX REPLACE ^/(.*) \\1 REL_CMAKE_DATA_DIR ${CMAKE_DATA_DIR})
+install(FILES cmake-help.vim cmake-indent.vim cmake-syntax.vim DESTINATION
${REL_CMAKE_DATA_DIR}/editors/vim)
+install(FILES cmake-mode.el DESTINATION ${REL_CMAKE_DATA_DIR}/editors/emacs)
ADD_SUBDIRECTORY (bash-completion)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5b97942cbb915e8eaff0b5b9fee0676296656c93
commit 5b97942cbb915e8eaff0b5b9fee0676296656c93
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sun Apr 22 19:08:29 2012 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Mon Apr 23 20:46:08 2012 +0200
Enhancement of bash completion scripts given by Igor Murzov.
The orginal patch has been reworked in order to follow
CMake source tree layout habit.
Inspired-By: Igor Murzov e-m...@date.by
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b1d5930..66f9b2d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -620,6 +620,9 @@ INSTALL(
WORLD_READ WORLD_EXECUTE
)
+# process docs related install
+ADD_SUBDIRECTORY(Docs)
+
#---
# End of the main section of the CMakeLists file
#---
diff --git a/Docs/CMakeLists.txt b/Docs/CMakeLists.txt
new file mode 100644
index 000..0848fef
--- /dev/null
+++ b/Docs/CMakeLists.txt
@@ -0,0 +1,2 @@
+string(REGEX REPLACE ^/(.*) \\1 REL_CMAKE_DATA_DIR ${CMAKE_DATA_DIR})
+ADD_SUBDIRECTORY (bash-completion)
diff --git a/Docs/bash-completion/CMakeLists.txt
b/Docs/bash-completion/CMakeLists.txt
new file mode 100644
index 000..592b71e
--- /dev/null
+++ b/Docs/bash-completion/CMakeLists.txt
@@ -0,0 +1,8 @@
+# Always install completion file in local dir
+# in order to be sure to always be able to install
+# in a local user directory rooted in a single directory.
+# packager should either patch that out or
+# add symlinks to the files in appropriate places
+# /etc/bash_completion.d/
+# DATADIR/completions (may be /usr/share/package/completions
+install(FILES cmake cpack ctest DESTINATION ${REL_CMAKE_DATA_DIR}/completions)
diff --git a/Docs/bash-completion/cmake b/Docs/bash-completion/cmake
new file mode 100644
index 000..59b565a
--- /dev/null
+++ b/Docs/bash-completion/cmake
@@ -0,0 +1,149 @@
+# bash completion for cmake(1) -*- shell-script -*-
+
+_cmake()
+{
+local cur prev words cword split=false
+_init_completion -n := || return
+
+# Workaround for options like -DCMAKE_BUILD_TYPE=Release
+local prefix=
+if [[ $cur == -D* ]]; then
+prev=-D
+prefix=-D
+cur=${cur#-D}
+elif [[ $cur == -U* ]]; then
+prev=-U
+prefix=-U
+cur=${cur#-U}
+fi
+
+case $prev in
+-D)
+if [[ $cur == *=* ]]; then
+# complete values for variables
+local var type value
+var=${cur%%[:=]*}
+value=${cur#*=}
+
+if [[ $cur == CMAKE_BUILD_TYPE* ]]; then # most widely used
case
+COMPREPLY=( $( compgen -W 'Debug Release RelWithDebInfo
+MinSizeRel' -- $value ) )
+
[Cmake-commits] CMake branch, master, updated. v2.8.8-22-g3d28c5d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 3d28c5dc47fec7257e2da3e6d9cc467632438b11 (commit) from 93e6069553874e11af8915da68996fb4323d4a52 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d28c5dc47fec7257e2da3e6d9cc467632438b11 commit 3d28c5dc47fec7257e2da3e6d9cc467632438b11 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Apr 24 00:01:03 2012 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Apr 24 00:01:03 2012 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 2c0122c..67f3d2f 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ SET(CMake_VERSION_MAJOR 2) SET(CMake_VERSION_MINOR 8) SET(CMake_VERSION_PATCH 8) -SET(CMake_VERSION_TWEAK 20120423) +SET(CMake_VERSION_TWEAK 20120424) #SET(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
