Re: [cmake-developers] setting LINKER_LANGUAGE still adds -lstdc++
On Mon, Oct 8, 2012 at 10:40 PM, James Bigler jamesbig...@gmail.com wrote:
In my project I need to manually link against a special version of
libstdc++, so I manually set the target link language to C and then add my
special library to the link line. On Linux this seems to work just fine,
but on OSX it still add -lstdc++ to the link like. Here's my cmake code:
cmake_minimum_required(VERSION 2.8)
project(linking_fun)
add_library(a SHARED a.cpp)
set_target_properties(a PROPERTIES LINKER_LANGUAGE C)
add_library(b SHARED b.c)
a.cpp and b.c both simply have 'int foo() { return 3;}'
And here's the compiler output which has the -lstdc++ on the link line for
library a, but not for library b.
Linking C shared library liba.dylib
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/a.dir/link.txt
--verbose=1
/usr/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -o
liba.dylib -install_name
/Users/jbigler/code/temp/cmake/static-libstdcpp/liba.dylib
CMakeFiles/a.dir/a.cpp.o
-lstdc++/usr/bin/../lib/clang/4.0/lib/darwin/libclang_rt.osx.a
/opt/local/bin/cmake -E cmake_progress_report
/Users/jbigler/code/temp/cmake/static-libstdcpp/CMakeFiles 1
[ 50%] Built target a
make -f CMakeFiles/b.dir/build.make CMakeFiles/b.dir/depend
cd /Users/jbigler/code/temp/cmake/static-libstdcpp
/opt/local/bin/cmake -E cmake_depends Unix Makefiles
/Users/jbigler/code/temp/cmake/static-libstdcpp
/Users/jbigler/code/temp/cmake/static-libstdcpp
/Users/jbigler/code/temp/cmake/static-libstdcpp
/Users/jbigler/code/temp/cmake/static-libstdcpp
/Users/jbigler/code/temp/cmake/static-libstdcpp/CMakeFiles/b.dir/DependInfo.cmake
--color=
make -f CMakeFiles/b.dir/build.make CMakeFiles/b.dir/build
Linking C shared library libb.dylib
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/b.dir/link.txt
--verbose=1
/usr/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -o
libb.dylib -install_name
/Users/jbigler/code/temp/cmake/static-libstdcpp/libb.dylib
CMakeFiles/b.dir/b.c.o
Is this a bug or a feature?
James
I spent some time in the debugger to try and understand why CMake is making
the decisions it is. It comes down to this function which loops over all
the LinkClosures and calls AddImplicitLinkInfo for all languages that
*don't* match the language of the target.
//
void cmComputeLinkInformation::AddImplicitLinkInfo()
{
// The link closure lists all languages whose implicit info is needed.
cmTarget::LinkClosure const*
lc=this-Target-GetLinkClosure(this-Config);
for(std::vectorstd::string::const_iterator li = lc-Languages.begin();
li != lc-Languages.end(); ++li)
{
// Skip those of the linker language. They are implicit.
if(*li != this-LinkLanguage)
{
this-AddImplicitLinkInfo(*li);
}
}
}
The LinkClosure is computed and the only language in it is CXX due to the
CXX-ness of the input sources. I'm not sure what to think about this. I
told CMake to link the target as if it were a C target, then it decides
that it needs CXX libraries because it found CXX sources in my library.
If I go through the trouble of specifying that I want to link the library
as if it were C, why do the source files get to override my property?
It also seems to me that the source file language should only guide the
link language when the user didn't specify it explicitly.
James
--
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] setting LINKER_LANGUAGE still adds -lstdc++
On 10/09/2012 01:59 AM, James Bigler wrote: On Mon, Oct 8, 2012 at 10:40 PM, James Bigler jamesbig...@gmail.com mailto:jamesbig...@gmail.com wrote: In my project I need to manually link against a special version of libstdc++ add_library(a SHARED a.cpp) set_target_properties(a PROPERTIES LINKER_LANGUAGE C) add_library(b SHARED b.c) And here's the compiler output which has the -lstdc++ on the link line for library a, but not for library b. [snip] I told CMake to link the target as if it were a C target, then it decides that it needs CXX libraries because it found CXX sources in my library. If I go through the trouble of specifying that I want to link the library as if it were C, why do the source files get to override my property? CMake is using the C compiler to drive the link call as you request. That is all the LINKER_LANGUAGE property says: http://www.cmake.org/cmake/help/v2.8.9/cmake.html#prop_tgt:LINKER_LANGUAGE ...sets the language whose compiler is used to link the target... However CMake knows that the sources have C++ code so it still wants to link against the C++ runtime libraries. This is the same feature that allows one to link C++ and Fortran code together. It chooses the C++ linker and adds the Fortran runtime libs. It is a feature and it is working exactly as intended. The C++ runtime libraries are detected when the CXX language is enabled. There is a CMakeCXXCompiler.cmake file under the CMakeFiles directory of the top-level build directory. It contains settings like: SET(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES stdc++;m;c) SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES ...) Whenever C++ sources are found in a target CMake will make sure these libraries appear on the link line or are also implicit for the linker language. You can hide the C++ runtime libraries by erasing these values: set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES ) set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES ) That along with setting LINKER_LANGUAGE to C should do what you want. -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013579]: FortranCInterface.cmake does not pass CMAKE_BUILD_TYPE flags
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13579 == Reported By:Jordan Lefebvre Assigned To: == Project:CMake Issue ID: 13579 Category: Modules Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-10-09 11:16 EDT Last Modified: 2012-10-09 11:16 EDT == Summary:FortranCInterface.cmake does not pass CMAKE_BUILD_TYPE flags Description: In attempting to compile a mixed language static Windows executable, FortranCInterface.cmake breaks the cmake configuration. Windows MSVC and Intel compilers toggle between static and dynamic system/compiler libraries using /MT and /MD compiler flags respectively. /libs:static /threads and /libs:dll /threads are equivalent to /MT and /MD respectively. The issues stems from a difference in initialization across C/CXX flags and Fortran flags. The static/dynamic flags are initialized in the base CMAKE_Fortran_FLAGS while they are initialized in the CMAKE_[C|CXX}_FLAGS_CMAKE_BUILD_TYPE flags. FortranCInterface.cmake does not pass the BUILD_TYPE flags through to the subproject. This results in mixed dynamic and static libraries and multiply defined symbols at linking. Steps to Reproduce: 1) Create cmake configuration which utilizes FortranCInterface. 2) Use Intel compilers on Windows 3) Add these additional configuration options to a configuration script.bat: cmake ^ -D CMAKE_C_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /Zm1000 ^ -D CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR ^ -D CMAKE_Fortran_FLAGS:STRING=/W1 /nologo /fpp ^ -D CMAKE_C_FLAGS_RELEASE:STRING=/D_NDEBUG /O2 /MT ^ -D CMAKE_CXX_FLAGS_RELEASE:STRING=/DNDEBUG /O2 /MT ^ -D CMAKE_Fortran_FLAGS_RELEASE:STRING=/D_NDEBUG /O2 /MT ^ -D CMAKE_Fortran_COMPILER:STRING=ifort ^ -D CMAKE_CXX_COMPILER:STRING=icl ^ -D CMAKE_C_COMPILER:STRING=icl ^ -G NMake Makefiles ^ %* 4) initialize Intel development environment 5) run script.bat path/to/src Additional Information: This could be fixed by standardizing the initialization of compiler flags across all languages or passing all compiler flags through to the FortranCInterface subproject. This prevents a static Windows build for executable deployment. It would be convenient to have this fixed as soon as possible. == Issue History Date ModifiedUsername FieldChange == 2012-10-09 11:16 Jordan LefebvreNew 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] Testing that solution contains what it should
Hi all, I have a question about tests of CMake itself. I'd like to create a new feature patch and I would definitely want to supply tests with it. Is there a standard mechanism (perhaps something like the macro check_cmake_test()) to test that a generated buildsystem (specifically, Visual Studio solution) contains what it should? If not, are there some test for this which I could take insipration from? I tried looking around in the test setup myself, but it feels quite complicated. I found a test (SourceGroups) which I believe would require similar functionality, but it doesn't seem to actually inspect the generated solution (or I couldn't find how it does). Thanks in advance for any help or pointers you can offer. Petr -- 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] Testing that solution contains what it should
On 10/09/2012 04:32 PM, Petr Kmoch wrote: Is there a standard mechanism (perhaps something like the macro check_cmake_test()) to test that a generated buildsystem (specifically, Visual Studio solution) contains what it should? If not, are there some test for this which I could take insipration from? AFAIK the only test that actually checks the content of a .sln file directly was added here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4a30258d All other tests just verify that the generated build system behaves as expected (with varying degrees of completeness). I found a test (SourceGroups) which I believe would require similar functionality, but it doesn't seem to actually inspect the generated solution That is a very old test and it pre-dated much of our current testing capabilities. IIRC it just verifies that projects actually build when source groups are set, but not that the IDE actually presents the groups. The latter is quite hard to do robustly but perhaps some kind of .vcproj / .vcxproj.filters parsing could be added to the test. -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] setting LINKER_LANGUAGE still adds -lstdc++
On Mon, Oct 8, 2012 at 10:40 PM, James Bigler jamesbig...@gmail.com wrote:
In my project I need to manually link against a special version of
libstdc++, so I manually set the target link language to C and then add my
special library to the link line. On Linux this seems to work just fine,
but on OSX it still add -lstdc++ to the link like. Here's my cmake code:
cmake_minimum_required(VERSION 2.8)
project(linking_fun)
add_library(a SHARED a.cpp)
set_target_properties(a PROPERTIES LINKER_LANGUAGE C)
add_library(b SHARED b.c)
a.cpp and b.c both simply have 'int foo() { return 3;}'
And here's the compiler output which has the -lstdc++ on the link line for
library a, but not for library b.
Linking C shared library liba.dylib
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/a.dir/link.txt
--verbose=1
/usr/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -o
liba.dylib -install_name
/Users/jbigler/code/temp/cmake/static-libstdcpp/liba.dylib
CMakeFiles/a.dir/a.cpp.o
-lstdc++/usr/bin/../lib/clang/4.0/lib/darwin/libclang_rt.osx.a
/opt/local/bin/cmake -E cmake_progress_report
/Users/jbigler/code/temp/cmake/static-libstdcpp/CMakeFiles 1
[ 50%] Built target a
make -f CMakeFiles/b.dir/build.make CMakeFiles/b.dir/depend
cd /Users/jbigler/code/temp/cmake/static-libstdcpp
/opt/local/bin/cmake -E cmake_depends Unix Makefiles
/Users/jbigler/code/temp/cmake/static-libstdcpp
/Users/jbigler/code/temp/cmake/static-libstdcpp
/Users/jbigler/code/temp/cmake/static-libstdcpp
/Users/jbigler/code/temp/cmake/static-libstdcpp
/Users/jbigler/code/temp/cmake/static-libstdcpp/CMakeFiles/b.dir/DependInfo.cmake
--color=
make -f CMakeFiles/b.dir/build.make CMakeFiles/b.dir/build
Linking C shared library libb.dylib
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/b.dir/link.txt
--verbose=1
/usr/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -o
libb.dylib -install_name
/Users/jbigler/code/temp/cmake/static-libstdcpp/libb.dylib
CMakeFiles/b.dir/b.c.o
Is this a bug or a feature?
James
I spent some time in the debugger to try and understand why CMake is making
the decisions it is. It comes down to this function which loops over all
the LinkClosures and calls AddImplicitLinkInfo for all languages that
*don't* match the language of the target.
//
void cmComputeLinkInformation::AddImplicitLinkInfo()
{
// The link closure lists all languages whose implicit info is needed.
cmTarget::LinkClosure const*
lc=this-Target-GetLinkClosure(this-Config);
for(std::vectorstd::string::const_iterator li = lc-Languages.begin();
li != lc-Languages.end(); ++li)
{
// Skip those of the linker language. They are implicit.
if(*li != this-LinkLanguage)
{
this-AddImplicitLinkInfo(*li);
}
}
}
The LinkClosure is computed and the only language in it is CXX due to the
CXX-ness of the input sources. I'm not sure what to think about this. I
told CMake to link the target as if it were a C target, then it decides
that it needs CXX libraries because it found CXX sources in my library.
If I go through the trouble of specifying that I want to link the library
as if it were C, why do the source files get to override my property?
It also seems to me that the source file language should only guide the
link language when the user didn't specify it explicitly.
James
--
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] setting LINKER_LANGUAGE still adds -lstdc++
2012/10/9 James Bigler jamesbig...@gmail.com: In my project I need to manually link against a special version of libstdc++, so I manually set the target link language to C and then add my special library to the link line. On Linux this seems to work just fine, but on OSX it still add -lstdc++ to the link like. Here's my cmake code: This doesn't seem to work on Linux either on my side, stdc++ gets in the link line as well: /usr/bin/cc -fPIC-shared -Wl,-soname,liba.so -o liba.so CMakeFiles/a.dir/a.cpp.o -lstdc++ -lm Did you try to fiddle with CMAKE_CXX_IMPLICIT_LINK_LIBRARIES ? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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-developers] setting LINKER_LANGUAGE still adds -lstdc++
2012/10/9 James Bigler jamesbig...@gmail.com:
I spent some time in the debugger to try and understand why CMake is making
the decisions it is. It comes down to this function which loops over all
the LinkClosures and calls AddImplicitLinkInfo for all languages that
*don't* match the language of the target.
//
void cmComputeLinkInformation::AddImplicitLinkInfo()
{
// The link closure lists all languages whose implicit info is needed.
cmTarget::LinkClosure const*
lc=this-Target-GetLinkClosure(this-Config);
for(std::vectorstd::string::const_iterator li = lc-Languages.begin();
li != lc-Languages.end(); ++li)
{
// Skip those of the linker language. They are implicit.
if(*li != this-LinkLanguage)
{
this-AddImplicitLinkInfo(*li);
}
}
}
The LinkClosure is computed and the only language in it is CXX due to the
CXX-ness of the input sources. I'm not sure what to think about this. I
told CMake to link the target as if it were a C target, then it decides that
it needs CXX libraries because it found CXX sources in my library.
If I go through the trouble of specifying that I want to link the library as
if it were C, why do the source files get to override my property?
It also seems to me that the source file language should only guide the link
language when the user didn't specify it explicitly.
I agree with you even if it looks like a feature side-effect.
It looks like if you need to
set(CMAKE_CXX_LINKER_PREFERENCE_PROPAGATES 0)
in order to make your current problem disappear (at least on Linux)
I would bet that this feature did not include a test with a single
source file.
I would also bet that Brad should answer to this:
commit fcab87c9f802965318bee033c2fa3ff27cfbfec7
Author: Brad King brad.k...@kitware.com
Date: Thu Jul 30 10:59:37 2009 -0400
Do not always propagate linker language preference
The commit Consider link dependencies for link language taught CMake
to propagate linker language preference from languages compiled into
libraries linked by a target. It turns out this should only be done for
some languages, such as C++, because normally the language of the
program entry point (main) should be used.
We introduce variable CMAKE_LANG_LINKER_PREFERENCE_PROPAGATES to tell
CMake whether a language should propagate its linker preference across
targets. Currently it is true only for C++.
commit fd633b33cff397b110cc69f82fd522cdf905952a
Author: Brad King brad.k...@kitware.com
Date: Thu Jul 30 10:59:25 2009 -0400
Refactor target linker language selection
This factors the decision logic out of cmTarget::ComputeLinkClosure into
dedicated class cmTargetSelectLinker. We replace several local
variables with a single object instance, and organize code into methods.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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] link errors using OpenMP
At least for gcc I think you can fix this by passing
${OpenMP_CXX_FLAGS} to the linker as well (e.g. LINKER_FLAGS target
property).
-fopenmp at the link stage will instruct gcc to pass the appropriate
libraries to the linker.
Nils
On 10/08/2012 11:30 PM, Matthew Woehlke wrote:
When I write a simple program using OpenMP, with a CMakeLists.txt like:
find_package(OpenMP REQUIRED)
add_definitions(${OpenMP_CXX_FLAGS})
add_executable(foo foo.cpp)
I get link errors:
foo.cpp: undefined reference to `omp_get_num_threads'
foo.cpp: undefined reference to `omp_get_thread_num'
...etc.
This is caused by the .o containing references to OMP methods, but the
linker does not link to the platform OpenMP library (e.g. libgomp.so
for gcc; similar issues seen with icc).
Does anyone have a preferred fix for this?
Ideas:
- find the appropriate library, set OpenMP_LIBRARY
- add OpenMP_C[XX]_FLAGS to target's LINK_FLAGS property
For the moment at least, I've solved this in my own project by
creating the following CMake function:
function(omp_add_flags TARGET LANG)
if(OPENMP_FOUND)
if(NOT LANG)
get_target_property(LANG ${TARGET} LINKER_LANGUAGE)
endif()
if(LANG MATCHES C(XX)?)
set_property(TARGET ${TARGET} APPEND
PROPERTY COMPILE_FLAGS ${OpenMP_${LANG}_FLAGS})
set_property(TARGET ${TARGET} APPEND
PROPERTY LINK_FLAGS ${OpenMP_${LANG}_FLAGS})
else()
message(WARNING omp_add_flags: target '${TARGET}'
link language '${LANG}' is not supported)
endif()
endif()
endfunction()
This might need some tweaking, but if the general idea seems like the
best way, I would propose adding this to FindOpenMP.cmake.
--
Nils Gladitz, B.Sc.
DICOM, Konnektivität und Entwicklung
Scivis wissenschaftliche Bildverarbeitung GmbH
Bertha-von-Suttner-Str. 5
D-37085 Göttingen
GERMANY
Handelsregister Nr. / Trade Register No. B3100 Göttingen
Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland
Tel: 0049 (0)551 634181-28
E-Mail: glad...@scivis.de
Web: www.scivis.de
--
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] setting LINKER_LANGUAGE still adds -lstdc++
On Tue, Oct 9, 2012 at 12:07 AM, Eric Noulard eric.noul...@gmail.comwrote: 2012/10/9 James Bigler jamesbig...@gmail.com: In my project I need to manually link against a special version of libstdc++, so I manually set the target link language to C and then add my special library to the link line. On Linux this seems to work just fine, but on OSX it still add -lstdc++ to the link like. Here's my cmake code: This doesn't seem to work on Linux either on my side, stdc++ gets in the link line as well: /usr/bin/cc -fPIC-shared -Wl,-soname,liba.so -o liba.so CMakeFiles/a.dir/a.cpp.o -lstdc++ -lm Did you try to fiddle with CMAKE_CXX_IMPLICIT_LINK_LIBRARIES ? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org I can manually remove the library thusly: list(REMOVE_ITEM CMAKE_CXX_IMPLICIT_LINK_LIBRARIES stdc++) This works around the issue, but it is rather ugly (directory scoped rather than target scoped) and non-intuitive (there's no documentation for this flag - I had to dig it out of emails and source). -- 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] adding headers for QTCreator
Hi,
I try to add all header files in the include directory so they are visible
in QTCreator.
My attempt looks like this.
file(GLOB Demo_HEADERS RELATIVE ${CMAKE_SOURCE_DIR}/include *.h)
message(STATUS )
message(STATUS ${Demo_HEADERS})
message(STATUS )
add_library(headers SHARED ${Demo_HEADERS} Dummy.cpp)
Unfortunately the ${Demo_HEADERS} thing is empty :(
regards
--
Witold Eryk Wolski
Triemlistrasse 155
8047 Zuerich
--
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] adding headers for QTCreator
Hi Witold.
Using RELATIVE does not change where the files are looked for, only how
they are reported. I believe you need this:
file(GLOB Demo_HEADERS RELATIVE ${CMAKE_SOURCE_DIR}/include include/*.h)
Hope this help.
Petr
On Tue, Oct 9, 2012 at 9:34 AM, Witold E Wolski wewol...@gmail.com wrote:
Hi,
I try to add all header files in the include directory so they are visible
in QTCreator.
My attempt looks like this.
file(GLOB Demo_HEADERS RELATIVE ${CMAKE_SOURCE_DIR}/include *.h)
message(STATUS )
message(STATUS ${Demo_HEADERS})
message(STATUS )
add_library(headers SHARED ${Demo_HEADERS} Dummy.cpp)
Unfortunately the ${Demo_HEADERS} thing is empty :(
regards
--
Witold Eryk Wolski
Triemlistrasse 155
8047 Zuerich
--
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] setting LINKER_LANGUAGE still adds -lstdc++
2012/10/9 James Bigler jamesbig...@gmail.com: On Tue, Oct 9, 2012 at 12:07 AM, Eric Noulard eric.noul...@gmail.com wrote: 2012/10/9 James Bigler jamesbig...@gmail.com: In my project I need to manually link against a special version of libstdc++, so I manually set the target link language to C and then add my special library to the link line. On Linux this seems to work just fine, but on OSX it still add -lstdc++ to the link like. Here's my cmake code: This doesn't seem to work on Linux either on my side, stdc++ gets in the link line as well: /usr/bin/cc -fPIC-shared -Wl,-soname,liba.so -o liba.so CMakeFiles/a.dir/a.cpp.o -lstdc++ -lm Did you try to fiddle with CMAKE_CXX_IMPLICIT_LINK_LIBRARIES ? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org I can manually remove the library thusly: list(REMOVE_ITEM CMAKE_CXX_IMPLICIT_LINK_LIBRARIES stdc++) This works around the issue, but it is rather ugly (directory scoped rather than target scoped) and non-intuitive (there's no documentation for this flag - I had to dig it out of emails and source). There is documentation: $ cmake --help-variable CMAKE_LANG_IMPLICIT_LINK_LIBRARIES cmake version 2.8.9.20121008-g63baa CMAKE_LANG_IMPLICIT_LINK_LIBRARIES Implicit link libraries and flags detected for language LANG. Compilers typically pass language runtime library names and other flags when they invoke a linker. These flags are implicit link options for the compiler's language. CMake automatically detects these libraries and flags for each language and reports the results in this variable. Did you try CMAKE_CXX_LINKER_PREFERENCE_PROPAGATES as well ? Whatever the solution I agree this should be target specific. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] New wiki page CMake Live Cycle Considerations
Thanks for the roses, Alex ;-) On Monday, 8. October 2012, 20:24:32, Alexander Neundorf wrote: Hi, I just found this new page in the cmake wiki and I think this is very useful information: http://www.cmake.org/Wiki/CMake_Live_Cycle_Considerations Please help keeping it up-to-date Great work, Jzarl ! :-) Alex -- 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] Need cmake to work on AIX 5.3
Hi, I have to get a build of my product on AIX 5.3 (powerpc) because of backward compatibility concerns. The product builds fine on such a system using conventional gmake. However, cmake fails to identify the xlc/xlC compilers correctly and reports them as broken. What is the way to fix this? Could I force cmake to recognize the compilers correctly in some manual way. I tried using CMAKE_FORCE_C_COMPILER and CMAKE_FORCE_CXX_COMPILER but it didn't work. I am not sure of the arguments to pass either. Any help is greatly appreciated. Thanks, Arindam -- 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] Need cmake to work on AIX 5.3
Hi Arindam, Maybe you can try this way: http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F Xavier On Tue, Oct 9, 2012 at 11:58 AM, Arindam Mukherjee arindam.muker...@gmail.com wrote: Hi, I have to get a build of my product on AIX 5.3 (powerpc) because of backward compatibility concerns. The product builds fine on such a system using conventional gmake. However, cmake fails to identify the xlc/xlC compilers correctly and reports them as broken. What is the way to fix this? Could I force cmake to recognize the compilers correctly in some manual way. I tried using CMAKE_FORCE_C_COMPILER and CMAKE_FORCE_CXX_COMPILER but it didn't work. I am not sure of the arguments to pass either. Any help is greatly appreciated. Thanks, Arindam -- 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] New wiki page CMake Live Cycle Considerations
On 8 October 2012 19:24, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi, I just found this new page in the cmake wiki and I think this is very useful information: http://www.cmake.org/Wiki/CMake_Live_Cycle_Considerations Looks great. I was looking for something like this recently. However, shouldn't it be Life Cycle rather than Live Cycle? -- Matt Williams http://milliams.com -- 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] New wiki page CMake Live Cycle Considerations
On Tuesday, 9. October 2012, 12:25:51, Matt Williams wrote: On 8 October 2012 19:24, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi, I just found this new page in the cmake wiki and I think this is very useful information: http://www.cmake.org/Wiki/CMake_Live_Cycle_Considerations Looks great. I was looking for something like this recently. However, shouldn't it be Life Cycle rather than Live Cycle? Thanks, this is fixed now. Johannes -- 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-developers] setting LINKER_LANGUAGE still adds -lstdc++
On 10/09/2012 01:59 AM, James Bigler wrote: On Mon, Oct 8, 2012 at 10:40 PM, James Bigler jamesbig...@gmail.com mailto:jamesbig...@gmail.com wrote: In my project I need to manually link against a special version of libstdc++ add_library(a SHARED a.cpp) set_target_properties(a PROPERTIES LINKER_LANGUAGE C) add_library(b SHARED b.c) And here's the compiler output which has the -lstdc++ on the link line for library a, but not for library b. [snip] I told CMake to link the target as if it were a C target, then it decides that it needs CXX libraries because it found CXX sources in my library. If I go through the trouble of specifying that I want to link the library as if it were C, why do the source files get to override my property? CMake is using the C compiler to drive the link call as you request. That is all the LINKER_LANGUAGE property says: http://www.cmake.org/cmake/help/v2.8.9/cmake.html#prop_tgt:LINKER_LANGUAGE ...sets the language whose compiler is used to link the target... However CMake knows that the sources have C++ code so it still wants to link against the C++ runtime libraries. This is the same feature that allows one to link C++ and Fortran code together. It chooses the C++ linker and adds the Fortran runtime libs. It is a feature and it is working exactly as intended. The C++ runtime libraries are detected when the CXX language is enabled. There is a CMakeCXXCompiler.cmake file under the CMakeFiles directory of the top-level build directory. It contains settings like: SET(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES stdc++;m;c) SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES ...) Whenever C++ sources are found in a target CMake will make sure these libraries appear on the link line or are also implicit for the linker language. You can hide the C++ runtime libraries by erasing these values: set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES ) set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES ) That along with setting LINKER_LANGUAGE to C should do what you want. -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
[CMake] Question about find package in Module mode
Hello, I am using find_package in Module mode for a Library that is also build using cmake. The Library is build in a way that it can be used both from the build dir, and from the installed location. When using find_package it always seems to prefer the build dir version, which is somewhat surprising since I expect the default to be the (supposably more stable) installed version and that the build dir version (that could be broken at any time) needs some explicit interaction. Is the current state the way it is supposed to be? Can I force CMake to do what I want? Best regards Fabio -- Dipl.-Inf. Fabio Fracassi BZMM - Charite Fraunhofer IPK (bzmm.charite.de) Augustenburger Platz. 1 13353 Berlin Tel. +49 (0)30 / 450 555 185 -- 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] Question about find package in Module mode
Hi, On Tue, Oct 9, 2012 at 3:46 PM, Fabio Fracassi fabio.fraca...@charite.de wrote: Hello, I am using find_package in Module mode for a Library that is also build using cmake. The Library is build in a way that it can be used both from the build dir, and from the installed location. When using find_package it always seems to prefer the build dir version, which is somewhat surprising since I expect the default to be the (supposably more stable) installed version and that the build dir version (that could be broken at any time) needs some explicit interaction. Is the current state the way it is supposed to be? Can I force CMake to do what I want? Unless you happen to build in /usr or /usr/local CMake won't automatically find packages in module mode, so you must already be doing something to have cmake find the module from the builddir first. The documentation of the find_package function (cmake --help-command find_package) has quite extensive documentation about the paths that are being searched and their order. Whats your find_package call? Check which of the variables mentioned in the find_package docs are set before the find_package call. 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] Question about find package in Module mode
On 10/9/12 5:05 PM, Andreas Pakulat wrote: Hi, On Tue, Oct 9, 2012 at 4:42 PM, Fabio Fracassi fabio.fraca...@charite.de wrote: On 10/9/12 4:12 PM, Andreas Pakulat wrote: Hi, On Tue, Oct 9, 2012 at 3:46 PM, Fabio Fracassi fabio.fraca...@charite.de wrote: Hello, I am using find_package in Module mode for a Library that is also build using cmake. The Library is build in a way that it can be used both from the build dir, and from the installed location. When using find_package it always seems to prefer the build dir version, which is somewhat surprising since I expect the default to be the (supposably more stable) installed version and that the build dir version (that could be broken at any time) needs some explicit interaction. [...] Whats your find_package call? Check which of the variables mentioned in the find_package docs are set before the find_package call. Andreas Ups, sorry it is Config mode, of course, i.e. I do not have a FindMyLibrarty.cmake anywhere, but my Library does provide a MyLibrary-config.cmake in both the installed location and in its build dir. I was actually talking about Config as well and mixed up the two types myself too :) The call I use is just: find_package(MyLibrary) You could try explicitly disabling the module mode here to avoid pulling in a possibly existing Find-Module somewhere on CMAKE_MODULE_PATH. If that results in the same behaviour, then there's something else wrong. I checked, there is no FindMyLibrary.cmake anywhere on the system. The MyLibrary-config.cmake is indeed used, it is just the wrong one. I do not explicitly set any environment or cmake vars that affect find_package. The build dirs (both of my library and its client) are somewhere in home, and my libray is installed in /usr/local (and /usr/local/bin is in the PATH) The package registry for my library contains the pathes to the build dir. What do you mean with package registry here? It means the package registry where cmake stores previously build packages, which can be disabled with NO_CMAKE_PACKAGE_REGISTRY and is located in ~/.cmake/packages/name/* and which is searched as the 6th point. Does that mean the files installed into /usr/local/ reference the builddir? If that is the case then you probably didn't generate the config files properly. Can you post the generated files as well as the corresponding install(EXPORT) and install(TARGETS ... EXPORT) lines? No, those are ok, and indeed work if I manualy point to the installed dir. It is just that for some reason CMake prefers ~/build/MyLibrary/Mylibrary-config.cmake over /usr/local/lib/CMake/MyLibrary/Mylibrary-config.cmake Best regards Fabio -- Dipl.-Inf. Fabio Fracassi BZMM - Charite Fraunhofer IPK (bzmm.charite.de) Augustenburger Platz. 1 13353 Berlin Tel. +49 (0)30 / 450 555 185 -- 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] Need cmake to work on AIX 5.3
On 10/9/2012 5:58 AM, Arindam Mukherjee wrote: Hi, I have to get a build of my product on AIX 5.3 (powerpc) because of backward compatibility concerns. The product builds fine on such a system using conventional gmake. However, cmake fails to identify the xlc/xlC compilers correctly and reports them as broken. What is the way to fix this? Could I force cmake to recognize the compilers correctly in some manual way. I tried using CMAKE_FORCE_C_COMPILER and CMAKE_FORCE_CXX_COMPILER but it didn't work. I am not sure of the arguments to pass either. Any help is greatly appreciated. Can you post the errors that you are getting? There is no way to help with the information you have posted. You need the compiler to work, forcing it will just cause trouble later. We test on two different AIX machines nightly, so the compilers should work. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] Need cmake to work on AIX 5.3
On Tue, Oct 9, 2012 at 9:21 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/9/2012 5:58 AM, Arindam Mukherjee wrote: Hi, I have to get a build of my product on AIX 5.3 (powerpc) because of backward compatibility concerns. The product builds fine on such a system using conventional gmake. However, cmake fails to identify the xlc/xlC compilers correctly and reports them as broken. What is the way to fix this? Could I force cmake to recognize the compilers correctly in some manual way. I tried using CMAKE_FORCE_C_COMPILER and CMAKE_FORCE_CXX_COMPILER but it didn't work. I am not sure of the arguments to pass either. Any help is greatly appreciated. Can you post the errors that you are getting? There is no way to help with the information you have posted. You need the compiler to work, forcing it will just cause trouble later. We test on two different AIX machines nightly, so the compilers should work. Hi Bill, Here is the output of running cmake version 2.8.9 on AIX 5.2. http://pastebin.com/yM46Ncse What I can see is that cmake fails to identify the compiler. Perhaps for that reason it seems to be trying an erroneous command-line later: /usr/bin/xlc_r CMakeFiles/cmTryCompileExec3576455604.dir/testCCompiler.c.o -o cmTryCompileExec3576455604 /usr/lib /lib I have got the same results by exporting CC=xlc and CXX=xlC and also CC=xlc_r and CXX=xlC_r. The version of IBM Visual Age on these machines is v7.0. I do not encounter any problems with normal Makefile based builds using this toolchain. I built cmake from source on this machine without any problems. I have a functional cmake-based build of my product on AIX 6.1 and Visual Age v8.0 which runs without any issues. Thanks. Arindam -- 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] Need cmake to work on AIX 5.3
On 10/9/2012 3:06 PM, Arindam Mukherjee wrote: On Tue, Oct 9, 2012 at 9:21 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/9/2012 5:58 AM, Arindam Mukherjee wrote: Hi, I have to get a build of my product on AIX 5.3 (powerpc) because of backward compatibility concerns. The product builds fine on such a system using conventional gmake. However, cmake fails to identify the xlc/xlC compilers correctly and reports them as broken. What is the way to fix this? Could I force cmake to recognize the compilers correctly in some manual way. I tried using CMAKE_FORCE_C_COMPILER and CMAKE_FORCE_CXX_COMPILER but it didn't work. I am not sure of the arguments to pass either. Any help is greatly appreciated. Can you post the errors that you are getting? There is no way to help with the information you have posted. You need the compiler to work, forcing it will just cause trouble later. We test on two different AIX machines nightly, so the compilers should work. Hi Bill, Here is the output of running cmake version 2.8.9 on AIX 5.2. http://pastebin.com/yM46Ncse What I can see is that cmake fails to identify the compiler. Perhaps for that reason it seems to be trying an erroneous command-line later: /usr/bin/xlc_r CMakeFiles/cmTryCompileExec3576455604.dir/testCCompiler.c.o -o cmTryCompileExec3576455604 /usr/lib /lib I have got the same results by exporting CC=xlc and CXX=xlC and also CC=xlc_r and CXX=xlC_r. The version of IBM Visual Age on these machines is v7.0. I do not encounter any problems with normal Makefile based builds using this toolchain. I built cmake from source on this machine without any problems. I have a functional cmake-based build of my product on AIX 6.1 and Visual Age v8.0 which runs without any issues. Thanks. Arindam OK, so somehow it is adding /usr/lib /lib to the link line Can you send your CMakeCache.txt file and the files in here: CMakeFiles/ -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] Question about find package in Module mode
Hi, On Tue, Oct 9, 2012 at 5:39 PM, Fabio Fracassi fabio.fraca...@charite.de wrote: On 10/9/12 5:05 PM, Andreas Pakulat wrote: On Tue, Oct 9, 2012 at 4:42 PM, Fabio Fracassi What do you mean with package registry here? It means the package registry where cmake stores previously build packages, which can be disabled with NO_CMAKE_PACKAGE_REGISTRY and is located in ~/.cmake/packages/name/* and which is searched as the 6th point. Ah, never came across that part before. What happens if you explicitly disable searching the package registry? Does that mean the files installed into /usr/local/ reference the builddir? If that is the case then you probably didn't generate the config files properly. Can you post the generated files as well as the corresponding install(EXPORT) and install(TARGETS ... EXPORT) lines? No, those are ok, and indeed work if I manualy point to the installed dir. It is just that for some reason CMake prefers ~/build/MyLibrary/Mylibrary-config.cmake over /usr/local/lib/CMake/MyLibrary/Mylibrary-config.cmake Hmm, at this point I'd probably try cmake --trace and/or --debug-outpu and maybe also the output of --system-information to find out why cmake decides to load the config file from that location. Oh and I assume that your client thats using the config has its own build-directory, i.e. something like ~/build/client/ and there's no CMakeCache.txt in ~/build/ 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
[Cmake-commits] CMake branch, master, updated. v2.8.9-499-g7e9bc86
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 7e9bc866846d32e74e134d59a73dbfcb02d78158 (commit) from 63baa2032821a5f2328c2902f87771368b1b4a28 (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=7e9bc866846d32e74e134d59a73dbfcb02d78158 commit 7e9bc866846d32e74e134d59a73dbfcb02d78158 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Oct 9 00:01:15 2012 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Oct 9 00:01:15 2012 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 3328f68..cfbca69 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 9) -set(CMake_VERSION_TWEAK 20121008) +set(CMake_VERSION_TWEAK 20121009) #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
[Cmake-commits] CMake branch, next, updated. v2.8.9-1047-g8ee84ad
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 8ee84adf9c644f3fda8825cced371d153d263db6 (commit)
via 7aa99270fa77a13e8e710adc0098385403d6cf7a (commit)
via 78e54b99fed1bd4c899360c9df779205ce6b29ba (commit)
via d729e8b74ccdf14d809a1b7f9260a5a1d225c2bc (commit)
via 354face4fa234adfe6f056dc9d3039fc135ab4ef (commit)
via 8b3b88abd82a36daf541dfa7094f978e0be08efc (commit)
via b3d8f5dab7f33dba4f327ab7ef4bd7ea90d6b651 (commit)
via a4985a9af9ed9762c1a51c369981609dd24f7425 (commit)
via d70650d6c3c94d1d903eb7f21998861d8f7bf2c6 (commit)
via 4801eb633392eff95586709df570dabcdf0f5db1 (commit)
from f52c0911b7bcfbd06cbe2ff9d2e4276bc520e43f (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=8ee84adf9c644f3fda8825cced371d153d263db6
commit 8ee84adf9c644f3fda8825cced371d153d263db6
Merge: f52c091 7aa9927
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Oct 9 08:28:22 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Oct 9 08:28:22 2012 -0400
Merge topic 'generator-expression-bug-fixes' into next
7aa9927 GenEx: Don't use std::vector::at(int).
78e54b9 GenEx: Add tests for 0 and 1 expressions with literal commas.
d729e8b GenEx: Add test for $BOOL: with empty parameter.
354face GenEx: Ensure that the empty CONFIGURATION can be used
conditionally.
8b3b88a GenEx: Validate target and property names.
b3d8f5d GenEx: Parse comma after colon tokens specially
a4985a9 GenEx: Report actual target name not found, not 0 each time.
d70650d GenEx: Return after error reported.
4801eb6 GenEx: It is not an error to specify an empty parameter
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7aa99270fa77a13e8e710adc0098385403d6cf7a
commit 7aa99270fa77a13e8e710adc0098385403d6cf7a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Oct 4 11:21:05 2012 +0200
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Oct 9 08:26:56 2012 -0400
GenEx: Don't use std::vector::at(int).
It might not exist with GCC 2.9.
diff --git a/Source/cmGeneratorExpressionEvaluator.cxx
b/Source/cmGeneratorExpressionEvaluator.cxx
index 93895b3..92e2052 100644
--- a/Source/cmGeneratorExpressionEvaluator.cxx
+++ b/Source/cmGeneratorExpressionEvaluator.cxx
@@ -173,7 +173,7 @@ static const struct StrEqualNode : public
cmGeneratorExpressionNode
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
{
-return *parameters.begin() == parameters.at(1) ? 1 : 0;
+return *parameters.begin() == parameters[1] ? 1 : 0;
}
} strEqualNode;
@@ -281,7 +281,7 @@ static const struct TargetPropertyNode : public
cmGeneratorExpressionNode
std::string propertyName = *parameters.begin();
if (parameters.size() == 2)
{
- if (parameters.begin()-empty() parameters.at(1).empty())
+ if (parameters.begin()-empty() parameters[1].empty())
{
reportError(context, content-GetOriginalExpression(),
$TARGET_PROPERTY:tgt,prop expression requires a non-empty
@@ -297,7 +297,7 @@ static const struct TargetPropertyNode : public
cmGeneratorExpressionNode
}
std::string targetName = parameters.front();
- propertyName = parameters.at(1);
+ propertyName = parameters[1];
if (!nameValidator.find(targetName.c_str()))
{
if (!nameValidator.find(propertyName.c_str()))
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78e54b99fed1bd4c899360c9df779205ce6b29ba
commit 78e54b99fed1bd4c899360c9df779205ce6b29ba
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Oct 4 10:27:34 2012 +0200
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Oct 9 08:26:54 2012 -0400
GenEx: Add tests for 0 and 1 expressions with literal commas.
diff --git a/Tests/GeneratorExpression/CMakeLists.txt
b/Tests/GeneratorExpression/CMakeLists.txt
index 41639ac..8bc4f32 100644
--- a/Tests/GeneratorExpression/CMakeLists.txt
+++ b/Tests/GeneratorExpression/CMakeLists.txt
@@ -4,7 +4,9 @@ project(GeneratorExpression NONE)
add_custom_target(check ALL
COMMAND ${CMAKE_COMMAND}
-Dtest_0=$0:nothing
+-Dtest_0_with_comma=$0:-Wl,--no-undefined
-Dtest_1=$1:content
+-Dtest_1_with_comma=$1:-Wl,--no-undefined
-Dconfig=$CONFIGURATION
-Dtest_and_0=$AND:0
-Dtest_and_0_0=$AND:0,0
diff --git a/Tests/GeneratorExpression/check.cmake
b/Tests/GeneratorExpression/check.cmake
index fd1e2ab..ec1f130 100644
---
[Cmake-commits] CMake branch, next, updated. v2.8.9-1049-gbbbb1f3
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 1f3e010bd294fd0605a25a123579f407885e (commit)
via 74fc5983b953032f343b47f04a9e8a52e714f4b2 (commit)
from 8ee84adf9c644f3fda8825cced371d153d263db6 (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=1f3e010bd294fd0605a25a123579f407885e
commit 1f3e010bd294fd0605a25a123579f407885e
Merge: 8ee84ad 74fc598
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Oct 9 08:32:13 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Oct 9 08:32:13 2012 -0400
Merge topic 'ninja-dont-pollute-current-dir' into next
74fc598 Ninja: don't pollute current dir when using gui (#13495)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=74fc5983b953032f343b47f04a9e8a52e714f4b2
commit 74fc5983b953032f343b47f04a9e8a52e714f4b2
Author: Peter Kümmel syntheti...@gmx.net
AuthorDate: Wed Oct 3 16:14:45 2012 +0200
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Oct 9 08:30:03 2012 -0400
Ninja: don't pollute current dir when using gui (#13495)
diff --git a/Source/cmNinjaTargetGenerator.cxx
b/Source/cmNinjaTargetGenerator.cxx
index 612e047..8f8ec41 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -662,9 +662,19 @@ cmNinjaTargetGenerator
void
cmNinjaTargetGenerator
-::EnsureDirectoryExists(const std::string dir) const
+::EnsureDirectoryExists(const std::string path) const
{
- cmSystemTools::MakeDirectory(dir.c_str());
+ if (cmSystemTools::FileIsFullPath(path.c_str()))
+{
+cmSystemTools::MakeDirectory(path.c_str());
+}
+ else
+{
+const std::string fullPath = std::string(this-GetGlobalGenerator()-
+ GetCMakeInstance()-GetHomeOutputDirectory())
+ + / + path;
+cmSystemTools::MakeDirectory(fullPath.c_str());
+}
}
void
---
Summary of changes:
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, master, updated. v2.8.9-504-gf1049b9
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 f1049b9a3cf2975288b015ffa47b32228b07d9cc (commit) via 0594bee578fbe017f8ef194557b4cddfa12b7dae (commit) via 8093f6cedea37b488a1e7f61bc363e149fa43428 (commit) via 06638039aaa01c5431e6b4f0c153390afbe82c46 (commit) via b74267745b012e1f3769ea5a7802c79f5480852b (commit) from 7e9bc866846d32e74e134d59a73dbfcb02d78158 (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=f1049b9a3cf2975288b015ffa47b32228b07d9cc commit f1049b9a3cf2975288b015ffa47b32228b07d9cc Merge: 7e9bc86 0594bee Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:34:40 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Oct 9 08:34:40 2012 -0400 Merge topic 'FindGTK2Fixes' 0594bee FindGTK2: Update local changelog 8093f6c FindGTK2: #12596 Missing paths for FindGTK2 on NetBSD 0663803 FindGTK2: #12049 fix detection of header files on multiarch systems b742677 FindGTK2: Rollback lib64 changes which broke header file finding --- Summary of changes: Modules/FindGTK2.cmake | 53 --- 1 files changed, 40 insertions(+), 13 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, master, updated. v2.8.9-506-gaa0647c
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 aa0647ca9c28afb359066819f44eb101e42e8a2f (commit) via 188c73cb749ae0b248df05baf9ea6227b54864da (commit) from f1049b9a3cf2975288b015ffa47b32228b07d9cc (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=aa0647ca9c28afb359066819f44eb101e42e8a2f commit aa0647ca9c28afb359066819f44eb101e42e8a2f Merge: f1049b9 188c73c Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:37:31 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Oct 9 08:37:31 2012 -0400 Merge topic 'ninja-compile-OBJECT_DIR' 188c73c Ninja: also set OBJECT_DIR when compiling --- Summary of changes: Source/cmNinjaTargetGenerator.cxx | 10 +- 1 files changed, 9 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
[Cmake-commits] CMake branch, master, updated. v2.8.9-508-g7da986b
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 7da986bb6c3cb82a1853420377bb7be5fb581f81 (commit) via 74fc5983b953032f343b47f04a9e8a52e714f4b2 (commit) from aa0647ca9c28afb359066819f44eb101e42e8a2f (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=7da986bb6c3cb82a1853420377bb7be5fb581f81 commit 7da986bb6c3cb82a1853420377bb7be5fb581f81 Merge: aa0647c 74fc598 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:38:12 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Oct 9 08:38:12 2012 -0400 Merge topic 'ninja-dont-pollute-current-dir' 74fc598 Ninja: don't pollute current dir when using gui (#13495) --- Summary of changes: Source/cmNinjaTargetGenerator.cxx | 14 -- 1 files changed, 12 insertions(+), 2 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, master, updated. v2.8.9-510-gf413d28
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 f413d280bc3f249d631c279d9dd236cbd85fd39d (commit) via aa2e1e9caef92b10083a03c2ded5c937703e69b8 (commit) from 7da986bb6c3cb82a1853420377bb7be5fb581f81 (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=f413d280bc3f249d631c279d9dd236cbd85fd39d commit f413d280bc3f249d631c279d9dd236cbd85fd39d Merge: 7da986b aa2e1e9 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:38:54 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Oct 9 08:38:54 2012 -0400 Merge topic 'ninja-custom-command-implicit' aa2e1e9 Ninja: implicit dependency for custom command files --- Summary of changes: Source/cmNinjaTargetGenerator.cxx |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
[Cmake-commits] CMake branch, master, updated. v2.8.9-512-g76f3fe7
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 76f3fe73baffd6b5b13e01d25e90789e84a38de8 (commit) via ea17faac4d9df954361c90eecc7c6c3d6f7e30e1 (commit) from f413d280bc3f249d631c279d9dd236cbd85fd39d (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=76f3fe73baffd6b5b13e01d25e90789e84a38de8 commit 76f3fe73baffd6b5b13e01d25e90789e84a38de8 Merge: f413d28 ea17faa Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:39:11 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Oct 9 08:39:11 2012 -0400 Merge topic 'ctest-svn-suncc-5.1' ea17faa cmCTestSVN: Fix compilation with Sun CC 5.1 --- Summary of changes: Source/CTest/cmCTestSVN.h |1 + Source/CTest/cmCTestVC.h |4 2 files changed, 5 insertions(+), 0 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, master, updated. v2.8.9-514-gfb4de44
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 fb4de4495dbdde59b5fb210f0cbb835ebf5d7a6a (commit) via e2b1630830201b3021dff19a3c98c4601693f269 (commit) from 76f3fe73baffd6b5b13e01d25e90789e84a38de8 (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=fb4de4495dbdde59b5fb210f0cbb835ebf5d7a6a commit fb4de4495dbdde59b5fb210f0cbb835ebf5d7a6a Merge: 76f3fe7 e2b1630 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:39:25 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Oct 9 08:39:25 2012 -0400 Merge topic 'DocumentCMakeFindPackageName' e2b1630 Document CMAKE_FIND_PACKAGE_NAME --- Summary of changes: Modules/readme.txt |3 +++ 1 files changed, 3 insertions(+), 0 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, master, updated. v2.8.9-524-g53c2dad
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 53c2dada1c4019ed21f14f33618a975a9652c84e (commit)
via 7aa99270fa77a13e8e710adc0098385403d6cf7a (commit)
via 78e54b99fed1bd4c899360c9df779205ce6b29ba (commit)
via d729e8b74ccdf14d809a1b7f9260a5a1d225c2bc (commit)
via 354face4fa234adfe6f056dc9d3039fc135ab4ef (commit)
via 8b3b88abd82a36daf541dfa7094f978e0be08efc (commit)
via b3d8f5dab7f33dba4f327ab7ef4bd7ea90d6b651 (commit)
via a4985a9af9ed9762c1a51c369981609dd24f7425 (commit)
via d70650d6c3c94d1d903eb7f21998861d8f7bf2c6 (commit)
via 4801eb633392eff95586709df570dabcdf0f5db1 (commit)
from fb4de4495dbdde59b5fb210f0cbb835ebf5d7a6a (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=53c2dada1c4019ed21f14f33618a975a9652c84e
commit 53c2dada1c4019ed21f14f33618a975a9652c84e
Merge: fb4de44 7aa9927
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Oct 9 08:40:07 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Oct 9 08:40:07 2012 -0400
Merge topic 'generator-expression-bug-fixes'
7aa9927 GenEx: Don't use std::vector::at(int).
78e54b9 GenEx: Add tests for 0 and 1 expressions with literal commas.
d729e8b GenEx: Add test for $BOOL: with empty parameter.
354face GenEx: Ensure that the empty CONFIGURATION can be used
conditionally.
8b3b88a GenEx: Validate target and property names.
b3d8f5d GenEx: Parse comma after colon tokens specially
a4985a9 GenEx: Report actual target name not found, not 0 each time.
d70650d GenEx: Return after error reported.
4801eb6 GenEx: It is not an error to specify an empty parameter
---
Summary of changes:
Source/cmGeneratorExpressionEvaluator.cxx | 65 +---
Source/cmGeneratorExpressionParser.cxx | 12 ++--
Tests/GeneratorExpression/CMakeLists.txt |5 ++
Tests/GeneratorExpression/check.cmake |5 ++
.../RunCMake/GeneratorExpression/BadNOT-stderr.txt |2 +-
.../{BadAND-result.txt = BadStrEqual-result.txt} |0
.../GeneratorExpression/BadStrEqual-stderr.txt | 38 +++
.../RunCMake/GeneratorExpression/BadStrEqual.cmake |6 ++
.../GeneratorExpression/RunCMakeTest.cmake |1 +
.../BadInvalidName1-result.txt}|0
.../BadInvalidName1-stderr.txt |6 ++
.../BadInvalidName1.cmake |7 ++
.../BadInvalidName2-result.txt}|0
.../BadInvalidName2-stderr.txt |6 ++
.../BadInvalidName2.cmake |7 ++
.../BadInvalidName3-result.txt}|0
.../BadInvalidName3-stderr.txt |6 ++
.../BadInvalidName3.cmake |7 ++
.../BadInvalidName4-result.txt}|0
.../BadInvalidName4-stderr.txt |6 ++
.../BadInvalidName4.cmake |9 +++
.../BadInvalidName5-result.txt}|0
.../BadInvalidName5-stderr.txt |7 ++
.../BadInvalidName5.cmake |7 ++
.../BadInvalidName6-result.txt}|0
.../BadInvalidName6-stderr.txt |6 ++
.../BadInvalidName6.cmake |7 ++
.../BadInvalidName7-result.txt}|0
.../BadInvalidName7-stderr.txt |6 ++
.../BadInvalidName7.cmake |9 +++
.../BadInvalidName8-result.txt}|0
.../BadInvalidName8-stderr.txt |6 ++
.../BadInvalidName8.cmake |7 ++
.../BadNonTarget-result.txt} |0
.../BadNonTarget-stderr.txt|6 ++
.../BadNonTarget.cmake |7 ++
.../RunCMakeTest.cmake |9 +++
37 files changed, 250 insertions(+), 15 deletions(-)
copy Tests/RunCMake/GeneratorExpression/{BadAND-result.txt =
BadStrEqual-result.txt} (100%)
create mode 100644 Tests/RunCMake/GeneratorExpression/BadStrEqual-stderr.txt
create mode 100644 Tests/RunCMake/GeneratorExpression/BadStrEqual.cmake
copy Tests/RunCMake/{GeneratorExpression/BadAND-result.txt =
TargetPropertyGeneratorExpressions/BadInvalidName1-result.txt} (100%)
create mode 100644
[Cmake-commits] CMake branch, master, updated. v2.8.9-526-gc8da8dd
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 c8da8dd3a390010cd5e3038eb806376f244ba60d (commit) via f63304d982d72e76541d40bbf35793a43e284fe9 (commit) from 53c2dada1c4019ed21f14f33618a975a9652c84e (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=c8da8dd3a390010cd5e3038eb806376f244ba60d commit c8da8dd3a390010cd5e3038eb806376f244ba60d Merge: 53c2dad f63304d Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:40:30 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Oct 9 08:40:30 2012 -0400 Merge topic 'doc-if-NOTFOUND' f63304d if: Document that plain 'NOTFOUND' is a false constant --- Summary of changes: Source/cmIfCommand.h |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
[Cmake-commits] CMake branch, master, updated. v2.8.9-528-g3dd443b
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 3dd443b51026098eb4ec931ae8bb07f16abad37a (commit) via 0ed6ff7a2ede945f11d820a4f17536c67a5f0bf2 (commit) from c8da8dd3a390010cd5e3038eb806376f244ba60d (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=3dd443b51026098eb4ec931ae8bb07f16abad37a commit 3dd443b51026098eb4ec931ae8bb07f16abad37a Merge: c8da8dd 0ed6ff7 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:40:38 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Oct 9 08:40:38 2012 -0400 Merge topic 'doc-regex-range' 0ed6ff7 string: Clarify regex documentation of '-' behavior --- Summary of changes: Source/cmStringCommand.h |3 ++- 1 files changed, 2 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
[Cmake-commits] CMake branch, next, updated. v2.8.9-1063-g3c0dbc6
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 3c0dbc64cbed9139211d7e851d988fd117dfcf74 (commit) via 3dd443b51026098eb4ec931ae8bb07f16abad37a (commit) via c8da8dd3a390010cd5e3038eb806376f244ba60d (commit) via 53c2dada1c4019ed21f14f33618a975a9652c84e (commit) via fb4de4495dbdde59b5fb210f0cbb835ebf5d7a6a (commit) via 76f3fe73baffd6b5b13e01d25e90789e84a38de8 (commit) via f413d280bc3f249d631c279d9dd236cbd85fd39d (commit) via 7da986bb6c3cb82a1853420377bb7be5fb581f81 (commit) via aa0647ca9c28afb359066819f44eb101e42e8a2f (commit) via f1049b9a3cf2975288b015ffa47b32228b07d9cc (commit) via 7e9bc866846d32e74e134d59a73dbfcb02d78158 (commit) via 63baa2032821a5f2328c2902f87771368b1b4a28 (commit) via 69f296bd3686ba258c754b9ce2e2e17042d3536a (commit) via be9ebdb4c44124eb24b670fc26cd9174d31b9c6b (commit) from 1f3e010bd294fd0605a25a123579f407885e (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=3c0dbc64cbed9139211d7e851d988fd117dfcf74 commit 3c0dbc64cbed9139211d7e851d988fd117dfcf74 Merge: 1f3 3dd443b Author: Brad King brad.k...@kitware.com AuthorDate: Tue Oct 9 08:41:23 2012 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Oct 9 08:41:23 2012 -0400 Merge branch 'master' into next --- 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
