Re: [cmake-developers] GCC link options
On 07/25/2012 02:12 PM, J Decker wrote:
target_link_libraries( playcard --whole-archive
eltanin_sdl_deadstart_end --no-whole-archive ${COMMON_LIBRARIES} )
(the output link line looks like . libplaycard.a --whole-archive
eltanin_sdl_deadstart_end.a libcommon.a --no-whole-archive )
The only ordering guarantee is that the target being linked
(final executable or shared library) has its own sequence
first as specified by target_link_libraries. Transitive
dependencies of the libraries named at the first level will
all appear in order but may have other things inserted.
The only reliable place to put flags is in the top-level call
to target_link_libraries for the target getting linked. For
example:
add_executable(foo foo.c)
target_link_libraries(foo ${libs}
--whole-archive ${special} --no-whole-archive)
will result in
-o foo ${libs} --whole-archive ${special} --no-whole-archive ${depends}
Alternatively, using CMake 2.8.8 you can also use an object library:
add_library(eltanin_sdl_deadstart_end OBJECT src.c)
add_executable(foo foo.c $TARGET_OBJECTS:eltanin_sdl_deadstart_end)
target_link_libraries(foo ${libs})
That will ensure the desired objects end up in the executable.
They will be listed explicitly on the link line as .o files.
-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] (Almost) unused status values in the cmake bugtracker
Hi, for some reason I just checked how often the different status value are used in the CMake bug tracker: New: 262 Feedback: 11 Acknowledged: 4 Confirmed: 3 Backlog: 142 Assigned: 599 Resolved: 169 Closed: 2940 Beside that there are currently quite a few in New (262), the values Feedback, Acknowledged and Confirmed are more or less unused. Maybe they could be removed ? (I didn't check the other projects in the bug tracker) 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] GCC link options
Is there a super simple way to get the current build command for say
exectuable, string(replace) it, and then execute it in a custom
target?
On Wed, Jul 25, 2012 at 11:31 AM, Brad King brad.k...@kitware.com wrote:
On 07/25/2012 02:12 PM, J Decker wrote:
target_link_libraries( playcard --whole-archive
eltanin_sdl_deadstart_end --no-whole-archive ${COMMON_LIBRARIES} )
(the output link line looks like . libplaycard.a --whole-archive
eltanin_sdl_deadstart_end.a libcommon.a --no-whole-archive )
The only ordering guarantee is that the target being linked
(final executable or shared library) has its own sequence
first as specified by target_link_libraries. Transitive
dependencies of the libraries named at the first level will
all appear in order but may have other things inserted.
that is the behavior I observe, but, I don't understand why a library
would be inserted in the middle of a set of libraries...
The only reliable place to put flags is in the top-level call
to target_link_libraries for the target getting linked. For
example:
add_executable(foo foo.c)
target_link_libraries(foo ${libs}
--whole-archive ${special} --no-whole-archive)
will result in
-o foo ${libs} --whole-archive ${special} --no-whole-archive ${depends}
which goes back to remove all implied dependencies and make one big list.
Alternatively, using CMake 2.8.8 you can also use an object library:
add_library(eltanin_sdl_deadstart_end OBJECT src.c)
add_executable(foo foo.c $TARGET_OBJECTS:eltanin_sdl_deadstart_end)
target_link_libraries(foo ${libs})
That will ensure the desired objects end up in the executable.
They will be listed explicitly on the link line as .o files.
Ya, but some of the items added to the deadstart section are in .a
files, so it has to be after all of those also
Migrating to shared libraries can also solve this; but, turns out they
used circular references in the libraries
None of this is good news :(
Thanx though.
-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 0013439]: consecutive find_package(Boost ...) statements only find the static lib regardless of Boost_USE_STATIC_LIBS
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13439
==
Reported By:Pieter Swinkels
Assigned To:
==
Project:CMake
Issue ID: 13439
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-07-25 17:33 EDT
Last Modified: 2012-07-25 17:33 EDT
==
Summary:consecutive find_package(Boost ...) statements only
find the static lib regardless of Boost_USE_STATIC_LIBS
Description:
Consecutive find_package(Boost ...) statements for the same Boost component in
the same file CMakeLists.txt but
- the first time with Boost_USE_STATIC_LIBS to ON and
- the second time with BOOST_USE_STATIC_LIBS to OFF
always finds the static library.
Steps to Reproduce:
Try something like this:
set(Boost_USE_STATIC_LIBS ON)
find_package(Boost COMPONENTS unit_test_framework REQUIRED)
if (Boost_FOUND)
include_directories(${Boost_INCLUDE_DIRS})
endif (Boost_FOUND)
# ${BOOST_LIBRARIES} contains the static version of the library
add_executable(my-static-find-package-boost-test main-static.cpp)
target_link_libraries(my-static-find-package-boost-test ${Boost_LIBRARIES})
unset(Boost_LIBRARIES)
message(Boost_LIBRARIES: ${Boost_LIBRARIES})
set(Boost_USE_STATIC_LIBS OFF)
find_package(Boost COMPONENTS unit_test_framework REQUIRED)
if (Boost_FOUND)
include_directories(${Boost_INCLUDE_DIRS})
endif (Boost_FOUND)
# ${BOOST_LIBRARIES} still contains the static version of the library
add_executable(my-dynamic-find-package-boost-test main-dynamic.cpp)
target_link_libraries(my-dynamic-find-package-boost-test ${Boost_LIBRARIES})
Additional Information:
It is not that the dynamic library cannot be found. If I uncomment the first
invocation, clear the cache (!) and run cmake, the dynamic library is found.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-25 17:33 Pieter SwinkelsNew 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] How to define file access mode in file write function?
Hi, How do you control the file access permission when using file(WRITE filename content)? The cmake 2.8.8 manual does not seem allow to specify access permission in file(WRITE ..). Thank you. J -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-define-file-access-mode-in-file-write-function-tp7580965.html Sent from the CMake mailing list archive at Nabble.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] How to define file access mode in file write function?
Am Mittwoch, 25. Juli 2012 um 04:17:18, schrieb hce jupiter@gmail.com Hi, How do you control the file access permission when using file(WRITE filename content)? The cmake 2.8.8 manual does not seem allow to specify access permission in file(WRITE ..). But install() does. Thank you. J Kornel signature.asc Description: This is a digitally signed message part. -- 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] set ranlib/ar in toolchain file
On Thursday 05 July 2012, Eric Noulard wrote: ... I'm not familiar with the Fortran support of CMake but in any case I think it's worth a bug report and people knowing more than me about Fortran CMake will probable sort this out approriately. If you have a litte more time it would be nice to file this bug report refering to this ML thread. Just for reference, this is the bug report: http://public.kitware.com/Bug/view.php?id=13379 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
Re: [CMake] Paired values in an iterable data structure like map or tuple
On Friday 13 July 2012, Ateljevich, Eli wrote:
Hi,
I have a series of tests I would like to perform, some of which are serial
and some of which are mpi and should use np processors.
I would further prefer to be able to process this as a list of paired
values. The following is nothing but pseudocode, but it attempts to convey
the idea. The ability to pair attributes (either as tuples or as some sort
of map or dictionary) is something I would love to learn to emulate. Am I
missing an easy way to do this? Thanks -E
foreach(testname (test_serial_1,serial,na),
test_mpi_1,mpi,4),
test_mpi_2,mpi,2) )
maketest(${testname}[0], ${testname}[1],${testname}[2])
endforeach()
A map in C++:
std::mapstd::string, std::string m;
std::string key;
key = foo;
m[key] = CMake;
key = bar;
m[key] = Rules;
key = blub;
m[key] = !;
if (m.find(blah) == m.end())
printf(blah not found in map !);
std::string s = m[blub];
The same in CMake:
set(key foo)
set(FOO_${key} CMake)
set(key bar)
set(FOO_${key} Rules)
set(key blub)
set(FOO_${key} !)
if(FOO_blah)
message(STATUS blah not found in map !)
endif()
set(s ${FOO_blub})
A list of structs in C++
struct Foo
{
std::string s1;
std::string s2;
};
std::vectorFoo v;
Foo f;
f.s1=Alex;
f.s2 = Neundorf;
v.push_back(f);
f.s1=Bill;
f.s2 = Hoffman;
v.push_back(f);
for(std::vectorFoo::const_iterator it = v.begin(); it!=v.end(); ++it)
{
printf(s1: %s s2: %s\n, it-s1.c_str(), it-s2.c_str());
}
In CMake I can think of two ways to do this.
Once by using two lists in parallel
list(APPEND v_s1 Alex)
list(APPEND v_s2 Neundorf)
list(APPEND v_s1 Bill)
list(APPEND v_s2 Hoffman)
list(LENGTH v_s1 count)
math(EXPR count ${count}-1)
foreach(i RANGE ${count})
list(GET v_s1 ${i} s1)
list(GET v_s2 ${i} s2)
message(STATUS s1: ${s1} s2: ${s2})
endforeach()
and alternatively again using specially named variables (as for the map, but
using the index as suffix for the name), but this may be a bit ugly.
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
Re: [CMake] How to export the user-defined variable in to the parent directory?
On Saturday 14 July 2012, 黄光成 wrote:
my directory hierarchical is : dir1/dir2/dir3.
In dir3's CMakeLists.txt, I define a custom variable named 'xxx' using the
command set(xxx yyy). I want to use the variable 'xxx' in dir1's
CMakeLists.txt, how to do that? Can export the user-defined variable?
For getting a variable one level up, using PARENT_SCOPE should work:
set(foo abc PARENT_SCOPE)
Calling this in dir3 directly in the CMakeLists.txt (i.e. not in a function)
would set foo in dir2.
Alternatively, you can set a variable globally, via two ways:
set(foo abc CACHE STRING something... FORCE)
or using a GLOBAL property:
in dir1/dir2/dir3/:
set_property(GLOBAL )
and then access it from anywhere else
get_property(GLOBAL )
I think setting a directory property should also work:
in dir1/dir2/dir3/:
set_property(DIRECTORY PROPERTY foo abc)
then accessing it should also work from everywhere I think:
get_property(myFoo DIRECTORY ${CMAKE_SOURCE_DIR}/dir1/dir2/dir3 PROPERTY foo)
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
Re: [CMake] Should I create IMPORTED targets for executables?
On Saturday 14 July 2012, Stephen Kelly wrote: Hi, For Qt 5 I'm creating IMPORTED targets for all the libraries, which has several benefits. I'm not sure if there are any benefits to creating IMPORTED targets for the executables too? Yes, intended for crosscompiling. add_custom_command() and add_custom_target() support using the target name of an executable created in the project as command (instead of using the path to an executable). When crosscompiling a project, which contains code generators, you can do something like this: # somewhere at the top level: if(CMAKE_CROSSCOMPILING) # will find the exported executable targets exported and installed from a # native build of this project, which creates the imported target mycodegen find_package(MyProjectExecutables) endif() # then at the place where the code generator is built: if(NOT CMAKE_CROSSCOMPILING) add_executable(mycodegen mcg.c) endif() ... add_custom_command(... COMMAND mycodegen arg1 arg2) 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] Disabling C for C++-only projects
Hi, Out of curiosity (and thinking about saving a couple of seconds during the first cmake run) I tried just to use C++ as language for some KDE program. It turns out that without C enabled, standard modules like FindKDE, FindQt4 and FindJPEG don't run because they use the CheckSymbolExists module. I'm wondering if this counts as a bug in FindQt4 and FindKDE, because after all these two projects are C++, so any platform test should IMO be using the same compiler as the build-process does? Cheers, 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] creating an sdk wrapper and hiding implementation
On Wednesday 18 July 2012, Michael Toy wrote: we have a number of internally developed libraries which we use together. i am creating an sdk which wraps all the internal libraries, and presents a single api to customers. i have built a small test by hand, and it works like this % cc -c sdk_api.c % ln -r sdk_api.o libinternal1.a libinternal2.a -o sdk.o -exported_sybmols_list sdk_api_entry.txt % strip -x sdk.o % ar r libsdk.a sdk.o this creates a libsdk.a which ONLY has the api entry points exposed to customers and hides all the globals from the internal libraries. can't quite wrap my head how to express this in cmake's world of sources, libraries and targets. best i can think of is a custom target, which then depends on the internal libraries ( which are built in the same project ), and then somehow get the path names to the internal libraries to construct the link line, only i can't even figure out how to do that. anyone have a clue? we have ended up have tons of system specific target construction rules, so i don't mind if i have to write the custom target differently for different target OSes. So basically this combines several static libraries into one static library ? This is not really/kind of supported by cmake. Since 2.8.8 (I think) you can create OBJECT libraries: add_library(... OBJECT ...) which are basically only a set of object files, but can be used later on to be linked against. So you could build libinternal1.a and libinternal2.a as such OBJECT libs, and then create a library sdk which links against those two. I haven't tested this myself, but maybe it works and kind of does what you want ? 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
Re: [CMake] Disabling C for C++-only projects
Hi, On Wed, Jul 25, 2012 at 10:06 PM, Johannes Zarl johannes.z...@jku.at wrote: Hi, Out of curiosity (and thinking about saving a couple of seconds during the first cmake run) I tried just to use C++ as language for some KDE program. Really? Seconds? I mean the toolchain-stuff in CMake is more or less hardcoded anyway, there's not a lot of runtime-checking going on there. It turns out that without C enabled, standard modules like FindKDE, FindQt4 and FindJPEG don't run because they use the CheckSymbolExists module. I'm wondering if this counts as a bug in FindQt4 and FindKDE, because after all these two projects are C++, so any platform test should IMO be using the same compiler as the build-process does? Well, on all platforms I know it actually does use the same compiler, just under a different name :P Also some of the platforms don't have a C compiler at all anyway (or at least none that you'd call a proper C compiler by todays standards). That being said, technically you're correct, they should be using CheckCXXSymbolExists instead. 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] Disabling C for C++-only projects
On Wednesday 25 July 2012, Johannes Zarl wrote: Hi, Out of curiosity (and thinking about saving a couple of seconds during the first cmake run) I tried just to use C++ as language for some KDE program. It turns out that without C enabled, standard modules like FindKDE, FindQt4 and FindJPEG don't run because they use the CheckSymbolExists module. I'm wondering if this counts as a bug in FindQt4 and FindKDE, because after all these two projects are C++, so any platform test should IMO be using the same compiler as the build-process does? Yes, but I'd consider it a very low severity bug. 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
Re: [CMake] Relink to shared libs
On Friday 20 July 2012, Andreas Naumann wrote: If you are using the Makefile system, then the libraries are newer than your tests, so your tests seems to need an update. And sometimes programs need relinking, where should the build system now, if you really need the relinking? Yes, e.g. to make sure the library still has the necessary symbols. 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
Re: [CMake] Easier way to override variables
On Wednesday 18 July 2012, Yngve Inntjore Levinsen wrote: Hi Romain, Have a look at the help for the function set: $ cmake --help-command set If I understand the documentation, this should be what you are looking for: set(MY_VAR NEW_VALUE FORCE) I don't think this does what you want. It sets MY_VAR to NEW_VALUE;FORCE. set() without CACHE always sets/overrides anything set before. The only time when you may need to enforce overriding is when the variable in question is a cache variable. set(MY_VAR foo CACHE STRING docs...) set(MY_VAR bar CACHE STRING docs...) will leave MY_VAR at foo, since setting a value in the cache only actually sets its value if it is not yet in the cache. To set it anyway, you have to use FORCE: set(MY_VAR foo CACHE STRING docs...) set(MY_VAR bar CACHE STRING docs... FORCE) Using CACHE and non-CACHE variables with the same name may result in not quite obvious behaviour. 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
Re: [CMake] Disabling C for C++-only projects
On Wednesday, July 25, 2012 10:06:27 PM Johannes Zarl wrote: Hi, Out of curiosity (and thinking about saving a couple of seconds during the first cmake run) I tried just to use C++ as language for some KDE program. It turns out that without C enabled, standard modules like FindKDE, FindQt4 and FindJPEG don't run because they use the CheckSymbolExists module. I'm wondering if this counts as a bug in FindQt4 and FindKDE, because after all these two projects are C++, so any platform test should IMO be using the same compiler as the build-process does? This has already been fixed in FindQt4 since CMake 2.8.6. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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
[Cmake-commits] CMake branch, release, updated. v2.8.8-588-gcda3626
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, release has been updated via cda3626645fdf853bd1c802807ce4b6389904cb9 (commit) via 78c83bc2096a341d1ad29a8cb39774237b8ccf7a (commit) via e5126cf405b1eb3bbc97a273eee62327e0131165 (commit) via a51e1529e79ef46c8f7f346328c788a4e630e474 (commit) via c1bbdbff57651a24fd8d7d5abe67dd24e7e6ed27 (commit) via d8627aa5b9a7d3e0753cc43841cd74b553fb4cdf (commit) via 0f87f32fe39140d52bdf0f03289ad468ea4009c0 (commit) via a195ca98ba16c0b55ccb17639a7edfd15c8ddc2c (commit) via d44ff1bea94a60b4c7df6498da23c20833a2e3e7 (commit) via b5d9dba7b601e72b13781bcfac8a7e8bb995d095 (commit) via e5fce89ea881aeff6b3d813e2227289c12b1c8f5 (commit) via 17cb00e5dc5e6da85b6c33f5bf495ffae6f8af4a (commit) via 2b3a0dbeffc5368f1be7e425658d5162dbc0af7e (commit) via 8a0a918fbb62d615dfb839fcb8cd849e5f6165d8 (commit) via 9c0d0f969fc7635fa35bfa81512834f7e222390b (commit) via 1fc8df9ca22c23f42afa94a949918cda008b07ce (commit) via 7a3ecf5ed5eb12d39f4fb14c821efda0b6a64031 (commit) via e743fc0e177f7aaefa052fa4a28e3a704c169316 (commit) via d66512122bc704c439fd78b224680d7a7eb07f26 (commit) via b47cffa9b892b3f4bd3d99efb4e3130440af8300 (commit) via 9f7dc8391746f41b12b90625ad7aa364d2091ebf (commit) via 5d365b26ec6ce089f1a5e0bfed523cb5f916f1da (commit) via caeca30936fee174fd36cb3bb0ecb45847aae873 (commit) via d569f3ef15cd05f3a42788dba26abd1e0846c59e (commit) via b32000865869a1ee36000216e5766e012256782e (commit) via 52160bf68f2d3b948efda5a7a64642e7e0969d9e (commit) via b21cb9ff7407c0fecd069c61ebd0f6512aa2d602 (commit) via 7fa8e532b6f6148707f12c17c284194003d679e6 (commit) via 56aeac6e6424f54455850f54f6b71ae89f065fd3 (commit) via 7a6bc9e987b1f98529b5a43846eaa9fc7921f9da (commit) via 9e30289176c1aaee4df14e452e6590187355040f (commit) via 44ba4cfdb6471506db37634b032cf4fa3784f4f9 (commit) via 7751966297e3b68b6c9904300f96bb57882af11a (commit) via 207ec5c3b13726bbb61d29bb1191ddbe992f8c1c (commit) via 79a4e2bbdd0dfd8e2812160b118ac17f09d4bdb0 (commit) via 6b6c2e0b5c544a4a410f43f2f7bc721b20267dc3 (commit) via 74d1c88529caa6d048418ea36e09a1d446472d33 (commit) via 873f21ad1bcbf900025b7cbddb50b94b37d198aa (commit) via c3988ee871c99e31ad4d10e9033d89da902d5694 (commit) via f8e0a5109f104e894f450049a6c97f53bd378dae (commit) via f36c7b0bbe79592c7540740fe9cef747346ae2a4 (commit) via 5d885db416a4cec236ba6422868dc3db3d766bc4 (commit) via 3b2a01e80ef0faf626afd4c5031395c00e1c9ecd (commit) via 7bb56c511eaabf2071cd311b6cf14453651127e4 (commit) via 03bdaf545369d4438a8aece8d3cec603d3a99727 (commit) via 54d9713adb016423d20c610163726f80da435588 (commit) via 10686a17f4457fd6032543992538850be5cc8d88 (commit) via a1b803349b51a9a814cd8e309832991306ef2cf0 (commit) via 3ba74ad9d586816f7c60cc6f527148edf982871c (commit) via aff0029ee3d6be52f9fefc00c2ca416459a38b32 (commit) via a7b4e3a57b418aa4569cf3bbd484212e9b9b5c77 (commit) via 21f156c03bec7595b58862a58a3446ec453f7d85 (commit) via 0a3d6a19b7355218ebc6de61a501626fa2aceb33 (commit) via 75bbffbe1b66070df8ac68f1d8b556e7cb0d087c (commit) via cdfa14a4f5a1432383c379baf741a713a198809a (commit) via e5a27a44a7a400e62a5f64450ae2c4d3d2b91e5c (commit) via c8641037487fbce4e3901ad87087181c42b0d356 (commit) via 1cdeef795a9765091027656e5b904059da8fc1b1 (commit) via ae8124a04c414ebd11dd411bc3296849e3373157 (commit) via f478b52cd0f3b116c32d6218198ba8c77c555e8b (commit) via 6547f369e4c3b71071da8534fcbe141320389c82 (commit) via 78588e03435103fca17372278cbecf29c867eec1 (commit) via 84a18cb5d659602235cc995497f5fb016560d553 (commit) via 0c89c10cfcd9bdd11531e3680216235f5b34ac8e (commit) via 46546809f5c7c5d0b96902f12f764eebf8cc1d48 (commit) via 6c1609ea5509b503e6cd740858931ebb5823bf97 (commit) via 42592966c514015cef070d6b24a0c29f22ac2999 (commit) via 379984883665d86a9c593acda8b24713e200f9ba (commit) via 392a6541b51dac5080a32fde67bc8aefd92a7226 (commit) via a8c659cd6e39b14efb015e2bbee14b146a9f3be5 (commit) via 848f2201c59c3d19243ed093db6e9ffbfd7b4698 (commit) via 801f23fe517d305f5f38a38d534d2caec09d7ab8 (commit) from d1d34f88a7fbc66414097ca7e4e4b772cc51f51f (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 -
[Cmake-commits] CMake branch, master, updated. v2.8.8-584-gcac490a
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 cac490aa70cf4564178be033bf8ca76d9e15455e (commit) from e5126cf405b1eb3bbc97a273eee62327e0131165 (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=cac490aa70cf4564178be033bf8ca76d9e15455e commit cac490aa70cf4564178be033bf8ca76d9e15455e Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Jul 26 00:01:05 2012 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Jul 26 00:01:05 2012 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 4485444..bff81be 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 20120725) +SET(CMake_VERSION_TWEAK 20120726) #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
