[cmake-developers] [CMake 0014755]: Cannot use VisualStudio 2013 Express with Windows7.1SDK for 64Bit builds
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14755 == Reported By:jest Assigned To: == Project:CMake Issue ID: 14755 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-02-14 06:13 EST Last Modified: 2014-02-14 06:13 EST == Summary:Cannot use VisualStudio 2013 Express with Windows7.1SDK for 64Bit builds Description: I'm trying to use VisualStudio 2013 Express with the 64 Bit Compiler from VisualStudio 2010. Since VisualStudio 2010 Express doesn't contain the 64Bit compiler, Windows7.1SDK is required to. The Compiler test of CMake doesn't pass. Steps to Reproduce: tried cmake -G Visual Studio 12 Win64 -T v100 as well as cmake -G Visual Studio 12 Win64 -T Windows7.1SDK Workaround: cmake -G Visual Studio 12 Win64 and manually select Windows7.1SDK in VisualStudio == Issue History Date ModifiedUsername FieldChange == 2014-02-14 06:13 jest New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Objective-C support
On Thu, 13 Feb 2014 17:35:42 -0700, Steve Wilson said: I just pushed a small topic branch to stage the introduces support for Objective-C as a ‘supported’ language with a separate identity from C/ CXX. The topic name is ‘objective-c-support.’ Does that solve this by any chance: http://public.kitware.com/Bug/view.php?id=4756 Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] Objective-C support
Yes, it does, less support for Objective-C++. I haven’t add support for Objective-C++.It shouldn’t be too hard to add support for Objective-C++ though. On Feb 14, 2014, at 8:42 AM, Sean McBride s...@rogue-research.com wrote: On Thu, 13 Feb 2014 17:35:42 -0700, Steve Wilson said: I just pushed a small topic branch to stage the introduces support for Objective-C as a ‘supported’ language with a separate identity from C/ CXX. The topic name is ‘objective-c-support.’ Does that solve this by any chance: http://public.kitware.com/Bug/view.php?id=4756 Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] visual-studio-preprocessor-undefine fix for /U problems
On 2/13/2014 7:33 PM, Steve Wilson wrote: The topic is visual-studio-preprocessor-undefine. Thanks. The method cmVisualStudioGeneratorOptions ::OutputUndefinePreprocessorDefinitions appears to duplicate a lot of code from cmVisualStudioGeneratorOptions ::OutputPreprocessorDefinitions Please factor out and parameterize the common pieces to avoid the duplication. Also, the test case appears to undef a macro in a specific source file and test that it is undefined, but never defines the macro for the whole target so of course it will never be defined and the test will always pass. Thanks, -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-developers] visual-studio-preprocessor-undefine fix for /U problems
Will do. On Feb 14, 2014, at 11:26 AM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:33 PM, Steve Wilson wrote: The topic is visual-studio-preprocessor-undefine. Thanks. The method cmVisualStudioGeneratorOptions ::OutputUndefinePreprocessorDefinitions appears to duplicate a lot of code from cmVisualStudioGeneratorOptions ::OutputPreprocessorDefinitions Please factor out and parameterize the common pieces to avoid the duplication. Also, the test case appears to undef a macro in a specific source file and test that it is undefined, but never defines the macro for the whole target so of course it will never be defined and the test will always pass. Thanks, -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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Objective-C support
On 2/13/2014 7:35 PM, Steve Wilson wrote: The topic name is ‘objective-c-support.’ Currently if CXX is enabled then .m sources get compiled as CXX. See Modules/CMakeCXXCompiler.cmake.in: set(CMAKE_CXX_SOURCE_FILE_EXTENSIONS C;M;c++;cc;cpp;cxx;m;mm;CPP) In order to be compatible we need to make sure that is still the case. However, if OBJC is enabled then that should be preferred to CXX for .m sources. Is that the case with these changes? Please add test cases to cover these combinations. IMO the capitalization ObjC looks nicer than OBJC and will extend better to ObjCXX than OBJCXX. I have no strong preference if others disagree though. Thanks, -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 0014756]: RFE: Report changes to cached values
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14756 == Reported By:Ben Boeckel Assigned To: == Project:CMake Issue ID: 14756 Category: CMake Reproducibility:have not tried Severity: feature Priority: normal Status: new == Date Submitted: 2014-02-14 14:20 EST Last Modified: 2014-02-14 14:20 EST == Summary:RFE: Report changes to cached values Description: Add a variable to CMake such that it will report when a cached variable's value is different from the default being set. For example: set(var dflt CACHE STRING description) could output: path/to/CMakeLists.txt:42: var 'dflt' - 'cachedvalue' and could also, at the end of configure, print out a command line (or initial cache file) to be used to duplicate the build on another machine. I was thinking of 'CMAKE_REPORT_DELTA' as the control variable. Came up from a gn thread: https://groups.google.com/a/chromium.org/d/msg/gn-dev/la6vwV3x-o4/hkJJ78a7rqwJ == Issue History Date ModifiedUsername FieldChange == 2014-02-14 14:20 Ben BoeckelNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Objective-C support
On Feb 14, 2014, at 12:06 PM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:35 PM, Steve Wilson wrote: The topic name is ‘objective-c-support.’ Currently if CXX is enabled then .m sources get compiled as CXX. See Modules/CMakeCXXCompiler.cmake.in: set(CMAKE_CXX_SOURCE_FILE_EXTENSIONS C;M;c++;cc;cpp;cxx;m;mm;CPP) In order to be compatible we need to make sure that is still the case. However, if OBJC is enabled then that should be preferred to CXX for .m sources. There isn’t anything specific in the code to make an accounting for this type of requirement. I’ll see what I can do and update the tests. Is that the case with these changes? Please add test cases to cover these combinations. IMO the capitalization ObjC looks nicer than OBJC and will extend better to ObjCXX than OBJCXX. I have no strong preference if others disagree though. I don’t have a strong preference, but the preference I do have is for the OBJC (OBJCXX) form simply because it matches the capital cases of C and CXX in the CMAKE_* variables, which is the most common language type that users encounter. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Objective-C support
On 2/14/2014 3:08 PM, Steve Wilson wrote: the preference I do have is for the OBJC (OBJCXX) form simply because it matches the capital cases of C and CXX in the CMAKE_* variables We do have Fortran already: CMAKE_Fortran_FLAGS, etc. but this is a valid point: CMAKE_OBJC_FLAGS CMAKE_OBJCXX_FLAGS v. CMAKE_ObjC_FLAGS CMAKE_ObjCXX_FLAGS I think the uppercase names look nicer in the variable names so let's stick with what you proposed unless others chime in. Thanks, -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-developers] visual-studio-preprocessor-undefine fix for /U problems
On Feb 14, 2014, at 11:26 AM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:33 PM, Steve Wilson wrote: The topic is visual-studio-preprocessor-undefine. Thanks. The method cmVisualStudioGeneratorOptions ::OutputUndefinePreprocessorDefinitions appears to duplicate a lot of code from cmVisualStudioGeneratorOptions ::OutputPreprocessorDefinitions In the refactor of these functions, would you like to see that refactor as a separate commit or merged in with the commit for the other changes? SteveW signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] visual-studio-preprocessor-undefine fix for /U problems
On 2/14/2014 3:48 PM, Steve Wilson wrote: In the refactor of these functions, would you like to see that refactor as a separate commit or merged in with the commit for the other changes? I have a slight preference for a separate commit that first factors the common part out and calls it from the one site, and then the main commit that adds the new call site. I wouldn't reject it (for that reason) either way though. Thanks, -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-developers] visual-studio-preprocessor-undefine fix for /U problems
I pushed a updated version of the topic branch to stage. It refactors the OutputPreprocessorDefinitions method into a a new method OutputDefinitionsByTag and adds an argument that lets you specify the tag.I also fixed the test case. SteveW On Feb 14, 2014, at 11:26 AM, Brad King brad.k...@kitware.com wrote: On 2/13/2014 7:33 PM, Steve Wilson wrote: The topic is visual-studio-preprocessor-undefine. Thanks. The method cmVisualStudioGeneratorOptions ::OutputUndefinePreprocessorDefinitions appears to duplicate a lot of code from cmVisualStudioGeneratorOptions ::OutputPreprocessorDefinitions Please factor out and parameterize the common pieces to avoid the duplication. Also, the test case appears to undef a macro in a specific source file and test that it is undefined, but never defines the macro for the whole target so of course it will never be defined and the test will always pass. Thanks, -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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Objective-C support
On Mavericks (OS X 10.9) there are two STL implementations: libstdc++ and libc++. I’m adding support for Objective-C++ and on Mavericks it matters which C++ library is used for linking. Is there a standard mechanism already in place for handling the difference in CMake. I checked for the -stdlib command line flag in the sources, but didn’t find it anywhere.Or put it another way, do we require users to decide themselves with STL implementation to use? signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Objective-C support
On Fri, 14 Feb 2014 15:14:23 -0700, Steve Wilson said: On Mavericks (OS X 10.9) there are two STL implementations: libstdc++ and libc++. That was also the case in 10.7 and 10.8. In 10.9 the default changed from libstdc++ to libc++ though. I’m adding support for Objective-C++ and on Mavericks it matters which C++ library is used for linking. Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super stable. Is there a standard mechanism already in place for handling the difference in CMake. I checked for the -stdlib command line flag in the sources, but didn’t find it anywhere.Or put it another way, do we require users to decide themselves with STL implementation to use? To me, it's something the user (of CMake) chooses, very much like choosing to build as C89 or C99 or C++03 or C++11. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] Objective-C support
On Fri, Feb 14, 2014 at 17:22:13 -0500, Sean McBride wrote: Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super stable. Hmm? The only one I know of recently is 4.7.0 and 4.7.1 breaking std::string ABI with C++11 support enabled (4.7.2 fixed it to be compatible with 4.7.0 and I'd, personally, blacklist those two versions if you use C++11). --Ben -- 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] Objective-C support
On Fri, 14 Feb 2014 17:47:00 -0500, Ben Boeckel said: Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super stable. Hmm? The only one I know of recently is 4.7.0 and 4.7.1 breaking std::string ABI with C++11 support enabled (4.7.2 fixed it to be compatible with 4.7.0 and I'd, personally, blacklist those two versions if you use C++11). What I mean is that with C++, and STL especially, it's hard to build a library with a given compiler/standard library combination and link that library into an executable built with a different compiler/standard library combination. (Harder than with say C.) That's the case on any platform. I was only trying to point out that 10.9 Mavericks is not special in this regard. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] Objective-C support
I was really looking for a way to add the the STL library as a library on the command line and then I realized that I had forgotten that on the Mac, the Objective-C++ compiler driver is clang++/g++. I was only thinking about clang/gcc. Sorry for the noise. On Feb 14, 2014, at 4:02 PM, Sean McBride s...@rogue-research.com wrote: On Fri, 14 Feb 2014 17:47:00 -0500, Ben Boeckel said: Same in 10.7 and 10.8, and any OS really, since C++ ABIs are not super stable. Hmm? The only one I know of recently is 4.7.0 and 4.7.1 breaking std::string ABI with C++11 support enabled (4.7.2 fixed it to be compatible with 4.7.0 and I'd, personally, blacklist those two versions if you use C++11). What I mean is that with C++, and STL especially, it's hard to build a library with a given compiler/standard library combination and link that library into an executable built with a different compiler/standard library combination. (Harder than with say C.) That's the case on any platform. I was only trying to point out that 10.9 Mavericks is not special in this regard. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Objective-C support
On Fri, Feb 14, 2014 at 18:02:18 -0500, Sean McBride wrote: What I mean is that with C++, and STL especially, it's hard to build a library with a given compiler/standard library combination and link that library into an executable built with a different compiler/standard library combination. (Harder than with say C.) That's the case on any platform. I was only trying to point out that 10.9 Mavericks is not special in this regard. Ah, so standard library *compatibility*, not *stability* then? I agree with that. --Ben -- 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] Path vs. name preference during search.
Hi, what about searching multiple times, each time giving only the path you want (in order of prefference)? If I'm correct, once the library is found, next attempts to find it againg will be a no-op. -- Gruesse, Jakub From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Rob McDonald Sent: Donnerstag, 13. Februar 2014 19:21 To: Jean-Christophe Fillion-Robin Cc: CMake ML Subject: Re: [CMake] Path vs. name preference during search. Jc, That is an approach I have thought about. I even think I have looked at Slicer for how you work your CMake system. I prefer to use project-supplied FindLIB.cmake (or a slightly modified version thereof) because some of them do more than just setting LIBRARY, INCLUDE_DIR, and FOUND variables. Rather than duplicate everything done in the FindLIB.cmake script (which can have platform-dependent logic), I have gone the path of encouraging the FindLIB.cmake to find the one I want. Rob On Thu, Feb 13, 2014 at 10:09 AM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.commailto:jchris.filli...@kitware.com wrote: Hi Rob, Do address the use case you described, I usually explicitly set the path the library when built as an external project and rely only on the find_* command for the use_system case. See https://github.com/Slicer/Slicer/blob/c5a39acf7af28ba82cc0097c84d1ebda89cce3b4/SuperBuild/External_teem.cmake#L13-16 Hth Jc On Thu, Feb 13, 2014 at 12:51 PM, Rob McDonald rob.a.mcdon...@gmail.commailto:rob.a.mcdon...@gmail.com wrote: When I search for a given library, specifying multiple possible names and multiple hints for paths... FIND_LIBRARY( FINDME_LIB NAMES name1 name2 name3 HINTS path1 path2 path3 DOC Library to find) CMake seems to have a preference for name1, and it first searches all HINTS for name1. If it doesn't find name1, it moves to name2 and then searches all HINTS for name2, etc. I would prefer to have a preference for path1, no matter the name. Try for all names in path1, then move to path2, etc. Is there a way to toggle this behavior? Rob Background... Basically, I am using ExternalProject_Add to build a library. However, to make it possible to use the system-library instead, this is optional. I use a FindThelib.cmake so the main project works seamlessly either way. I'm targeting the case where a version of this library is installed on the system, but I want to use my own copy. The name of the library depends on build options and platform, so controlling on the name is a little fragile. However, I have explicitly built it in a known directory, so having preference for the known directory is desirable. -- Powered by www.kitware.comhttp://www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849tel:%2B1%20919%20869%208849 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Path vs. name preference during search.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, For more discussion on the search order of PATHS and NAMES used by the different Find_* commands see, e.g.: http://www.cmake.org/pipermail/cmake/2009-October/032565.html http://www.cmake.org/pipermail/cmake/2010-March/035889.html http://public.kitware.com/Bug/view.php?id=10718 The current CMake behaviour is not likely to change. IIRC, Bill Hoffman once explained that the NAMES option was introduced to specify name *aliases* like 'gtk' 'gtk12' in FindGTK.cmake. It was *not* meant to specify a list of names for *different* entities. Best regards, Marcel Loose. op 14-02-14 09:02, Jakub Zakrzewski schreef: Hi, what about searching multiple times, each time giving only the path you want (in order of prefference)? If I'm correct, once the library is found, next attempts to find it againg will be a no-op. -- Gruesse, Jakub *From:*CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Rob McDonald *Sent:* Donnerstag, 13. Februar 2014 19:21 *To:* Jean-Christophe Fillion-Robin *Cc:* CMake ML *Subject:* Re: [CMake] Path vs. name preference during search. Jc, That is an approach I have thought about. I even think I have looked at Slicer for how you work your CMake system. I prefer to use project-supplied FindLIB.cmake (or a slightly modified version thereof) because some of them do more than just setting LIBRARY, INCLUDE_DIR, and FOUND variables. Rather than duplicate everything done in the FindLIB.cmake script (which can have platform-dependent logic), I have gone the path of encouraging the FindLIB.cmake to find the one I want. Rob On Thu, Feb 13, 2014 at 10:09 AM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com mailto:jchris.filli...@kitware.com wrote: Hi Rob, Do address the use case you described, I usually explicitly set the path the library when built as an external project and rely only on the find_* command for the use_system case. See https://github.com/Slicer/Slicer/blob/c5a39acf7af28ba82cc0097c84d1ebda89cce3b4/SuperBuild/External_teem.cmake#L13-16 Hth Jc On Thu, Feb 13, 2014 at 12:51 PM, Rob McDonald rob.a.mcdon...@gmail.com mailto:rob.a.mcdon...@gmail.com wrote: When I search for a given library, specifying multiple possible names and multiple hints for paths... FIND_LIBRARY( FINDME_LIB NAMES name1 name2 name3 HINTS path1 path2 path3 DOC Library to find) CMake seems to have a preference for name1, and it first searches all HINTS for name1. If it doesn't find name1, it moves to name2 and then searches all HINTS for name2, etc. I would prefer to have a preference for path1, no matter the name. Try for all names in path1, then move to path2, etc. Is there a way to toggle this behavior? Rob Background... Basically, I am using ExternalProject_Add to build a library. However, to make it possible to use the system-library instead, this is optional. I use a FindThelib.cmake so the main project works seamlessly either way. I'm targeting the case where a version of this library is installed on the system, but I want to use my own copy. The name of the library depends on build options and platform, so controlling on the name is a little fragile. However, I have explicitly built it in a known directory, so having preference for the known directory is desirable. -- Powered by www.kitware.com http://www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 tel:%2B1%20919%20869%208849 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS/eiRAAoJEEpMyb1AIWdYJjwH/0IQjZhRXHVu2Z9UsFgGpPp6 m9EG9dEfRFoasd9QrmWwpl+JXTPlqHwS9xJO4QZFjJV4k86VwW9SxCheNaoVX+ro k4DBzdpsCniMxIwal03dICnPZjjZsNVGI2B5xayRW5spTn48kBWI0nA7OaDii/Ib p4/RK4hFBKbt89NAl/8u2fO36KFXCkro826lvLpIlmZ52rev35S3hZ8OuwNC4JIH PUKBxo7VM8Qg0MqSVsHL2rl3J9Uf88miTUKW0rO9fvHup969rqyqmjjpABRA4OK0 eQ0cVVoe2K//bLr4v+FiX/sb535qtfJDqlAevkvp24wOt5zM0erPyE162MbAcnE= =CcZH -END PGP SIGNATURE- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each
Re: [CMake] Run clean before automatically re-running cmake?
I'd only want to do a full build if one of the CMakeLists.txt has changed (cmake needs to get re-run). Otherwise, I'd like to do a normal build. On Thu, Feb 13, 2014 at 4:52 AM, Ian Liu Rodrigues ian.li...@gmail.comwrote: You are correct that I would prefer that behavior, however I'd prefer to go for safety (and do a full clean) until that more advanced logic can be implemented... I am in fact using ninja, so hopefully that feature may come down the pipe soon :-) If you want a full build, why don't you just rm -rf build mkdir build cd build cmake ..? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Run clean before automatically re-running cmake?
On 2/14/2014 11:00 AM, Abe Bachrach wrote: I'd only want to do a full build if one of the CMakeLists.txt has changed (cmake needs to get re-run). Otherwise, I'd like to do a normal build. That seems a bit over kill to me. I would rather have a few extra files than having a complete clean done each time a new file is added or a flag is changed in a CMake file. Here is what you should do 1. create a list of all the targets in your project 2. use configure file to save the list, but be tricky so that it saves the last version of the file as well. 3. add a custom command that all your targets depend on. The custom command should depend on the file that is configured. It will get run only when the file changes if you use copy on different. When the custom command runs it should diff the two files and figure out what target went away, and then remove it. Basically, you should be able to do this all from the CMake language with custom commands and a CMake script. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7720-g7e21d8d
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 7e21d8d7d49f1f2da42f331d768f8b5a46b7ecff (commit)
via e4c5b620c7bc48c9145aa1fe9b23b6f97d68ea22 (commit)
from 49b96a74d9ec86976328ed54ca801a73a44e (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=7e21d8d7d49f1f2da42f331d768f8b5a46b7ecff
commit 7e21d8d7d49f1f2da42f331d768f8b5a46b7ecff
Merge: 49b96a7 e4c5b62
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Feb 14 05:15:45 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 14 05:15:45 2014 -0500
Merge topic 'gcc-ipo' into next
e4c5b620 IPO: implemented INTERPROCEDURAL_OPTIMIZATION for gcc (-flto)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4c5b620c7bc48c9145aa1fe9b23b6f97d68ea22
commit e4c5b620c7bc48c9145aa1fe9b23b6f97d68ea22
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Jan 31 23:56:40 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Fri Feb 14 11:14:23 2014 +0100
IPO: implemented INTERPROCEDURAL_OPTIMIZATION for gcc (-flto)
Using the IPO specific rule variables in the Ninja generator should
fix intel IPO as well.
diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
index f01255c..a38ebce 100644
--- a/Modules/Compiler/GNU.cmake
+++ b/Modules/Compiler/GNU.cmake
@@ -55,4 +55,96 @@ macro(__compiler_gnu lang)
if(NOT APPLE)
set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} -isystem )
endif()
+
+ # LTO/IPO
+ if(NOT CMAKE_GCC_AR OR NOT CMAKE_GCC_RANLIB)
+if(IS_ABSOLUTE ${CMAKE_${lang}_COMPILER})
+ string(REGEX MATCH ^([0-9]+.[0-9]+) _version
+${CMAKE_${lang}_COMPILER_VERSION})
+ get_filename_component(_dir ${CMAKE_${lang}_COMPILER} DIRECTORY)
+
+ find_program(CMAKE_GCC_AR NAMES
+${_CMAKE_TOOLCHAIN_PREFIX}gcc-ar
+${_CMAKE_TOOLCHAIN_PREFIX}gcc-ar-${_version}
+DOC gcc provided wrapper for ar which adds the --plugin option
+ )
+
+ find_program(CMAKE_GCC_RANLIB NAMES
+${_CMAKE_TOOLCHAIN_PREFIX}gcc-ranlib
+${_CMAKE_TOOLCHAIN_PREFIX}gcc-ranlib-${_version}
+DOC gcc provided wrapper for ranlib which adds the --plugin option
+ )
+
+ mark_as_advanced(CMAKE_GCC_AR CMAKE_GCC_RANLIB)
+endif()
+ endif()
+
+ if(CMAKE_GCC_AR AND CMAKE_GCC_RANLIB)
+set(__lto_flags -flto)
+
+if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4.7)
+ list(APPEND __lto_flags -fno-fat-lto-objects)
+endif()
+
+if(NOT DEFINED CMAKE_${lang}_PASSED_LTO_TEST)
+ set(__output_dir ${CMAKE_PLATFORM_INFO_DIR}/LtoTest${lang})
+ file(MAKE_DIRECTORY ${__output_dir})
+ set(__output_base ${__output_dir}/lto-test-${lang})
+
+ execute_process(
+COMMAND ${CMAKE_COMMAND} -E echo void foo() {}
+COMMAND ${CMAKE_${lang}_COMPILER} ${__lto_flags} -c -xc -
+ -o ${__output_base}.o
+RESULT_VARIABLE __result
+ERROR_QUIET
+OUTPUT_QUIET
+ )
+
+ if(${__result} STREQUAL 0)
+execute_process(
+ COMMAND ${CMAKE_GCC_AR} cr ${__output_base}.a ${__output_base}.o
+ COMMAND ${CMAKE_GCC_RANLIB} ${__output_base}.a
+ RESULT_VARIABLE __result
+ ERROR_QUIET
+ OUTPUT_QUIET
+)
+ endif()
+
+ if(${__result} STREQUAL 0)
+execute_process(
+ COMMAND ${CMAKE_COMMAND} -E echo void foo(); int main() {foo();}
+ COMMAND ${CMAKE_${lang}_COMPILER} ${__lto_flags} -xc -
+-x none ${__output_base}.a -o ${__output_base}
+ RESULT_VARIABLE __result
+ ERROR_QUIET
+ OUTPUT_QUIET
+)
+ endif()
+
+ if(${__result} STREQUAL 0)
+set(__lto_found TRUE)
+ endif()
+
+ set(CMAKE_${lang}_PASSED_LTO_TEST
+${__lto_found} CACHE INTERNAL
+If the compiler passed a simple LTO test compile)
+endif()
+
+if(CMAKE_${lang}_PASSED_LTO_TEST)
+
+ set(CMAKE_${lang}_COMPILE_OPTIONS_IPO ${__lto_flags})
+
+ set(CMAKE_${lang}_ARCHIVE_CREATE_IPO
+${CMAKE_GCC_AR} cr TARGET LINK_FLAGS OBJECTS
+ )
+
+ set(CMAKE_${lang}_ARCHIVE_APPEND_IPO
+${CMAKE_GCC_AR} r TARGET LINK_FLAGS OBJECTS
+ )
+
+ set(CMAKE_${lang}_ARCHIVE_FINISH_IPO
+${CMAKE_GCC_RANLIB} TARGET
+ )
+endif()
+ endif()
endmacro()
diff --git a/Source/cmMakefileLibraryTargetGenerator.cxx
b/Source/cmMakefileLibraryTargetGenerator.cxx
index d6a0cd4..38d3c3c 100644
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx
@@ -140,11 +140,7 @@ void
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7722-ga06c946
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 a06c9465cf9c2dcc66a5b07327ecbe24ae667295 (commit)
via d07f430247406f682e01e8e2067b079e4fe2f4cf (commit)
from 7e21d8d7d49f1f2da42f331d768f8b5a46b7ecff (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=a06c9465cf9c2dcc66a5b07327ecbe24ae667295
commit a06c9465cf9c2dcc66a5b07327ecbe24ae667295
Merge: 7e21d8d d07f430
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Feb 14 05:17:06 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 14 05:17:06 2014 -0500
Merge topic 'gcc-ipo' into next
d07f4302 Revert IPO: implemented INTERPROCEDURAL_OPTIMIZATION for gcc
(-flto)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d07f430247406f682e01e8e2067b079e4fe2f4cf
commit d07f430247406f682e01e8e2067b079e4fe2f4cf
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Feb 14 11:16:05 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Fri Feb 14 11:16:05 2014 +0100
Revert IPO: implemented INTERPROCEDURAL_OPTIMIZATION for gcc (-flto)
This reverts commit e4c5b620c7bc48c9145aa1fe9b23b6f97d68ea22.
diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
index a38ebce..f01255c 100644
--- a/Modules/Compiler/GNU.cmake
+++ b/Modules/Compiler/GNU.cmake
@@ -55,96 +55,4 @@ macro(__compiler_gnu lang)
if(NOT APPLE)
set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} -isystem )
endif()
-
- # LTO/IPO
- if(NOT CMAKE_GCC_AR OR NOT CMAKE_GCC_RANLIB)
-if(IS_ABSOLUTE ${CMAKE_${lang}_COMPILER})
- string(REGEX MATCH ^([0-9]+.[0-9]+) _version
-${CMAKE_${lang}_COMPILER_VERSION})
- get_filename_component(_dir ${CMAKE_${lang}_COMPILER} DIRECTORY)
-
- find_program(CMAKE_GCC_AR NAMES
-${_CMAKE_TOOLCHAIN_PREFIX}gcc-ar
-${_CMAKE_TOOLCHAIN_PREFIX}gcc-ar-${_version}
-DOC gcc provided wrapper for ar which adds the --plugin option
- )
-
- find_program(CMAKE_GCC_RANLIB NAMES
-${_CMAKE_TOOLCHAIN_PREFIX}gcc-ranlib
-${_CMAKE_TOOLCHAIN_PREFIX}gcc-ranlib-${_version}
-DOC gcc provided wrapper for ranlib which adds the --plugin option
- )
-
- mark_as_advanced(CMAKE_GCC_AR CMAKE_GCC_RANLIB)
-endif()
- endif()
-
- if(CMAKE_GCC_AR AND CMAKE_GCC_RANLIB)
-set(__lto_flags -flto)
-
-if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4.7)
- list(APPEND __lto_flags -fno-fat-lto-objects)
-endif()
-
-if(NOT DEFINED CMAKE_${lang}_PASSED_LTO_TEST)
- set(__output_dir ${CMAKE_PLATFORM_INFO_DIR}/LtoTest${lang})
- file(MAKE_DIRECTORY ${__output_dir})
- set(__output_base ${__output_dir}/lto-test-${lang})
-
- execute_process(
-COMMAND ${CMAKE_COMMAND} -E echo void foo() {}
-COMMAND ${CMAKE_${lang}_COMPILER} ${__lto_flags} -c -xc -
- -o ${__output_base}.o
-RESULT_VARIABLE __result
-ERROR_QUIET
-OUTPUT_QUIET
- )
-
- if(${__result} STREQUAL 0)
-execute_process(
- COMMAND ${CMAKE_GCC_AR} cr ${__output_base}.a ${__output_base}.o
- COMMAND ${CMAKE_GCC_RANLIB} ${__output_base}.a
- RESULT_VARIABLE __result
- ERROR_QUIET
- OUTPUT_QUIET
-)
- endif()
-
- if(${__result} STREQUAL 0)
-execute_process(
- COMMAND ${CMAKE_COMMAND} -E echo void foo(); int main() {foo();}
- COMMAND ${CMAKE_${lang}_COMPILER} ${__lto_flags} -xc -
--x none ${__output_base}.a -o ${__output_base}
- RESULT_VARIABLE __result
- ERROR_QUIET
- OUTPUT_QUIET
-)
- endif()
-
- if(${__result} STREQUAL 0)
-set(__lto_found TRUE)
- endif()
-
- set(CMAKE_${lang}_PASSED_LTO_TEST
-${__lto_found} CACHE INTERNAL
-If the compiler passed a simple LTO test compile)
-endif()
-
-if(CMAKE_${lang}_PASSED_LTO_TEST)
-
- set(CMAKE_${lang}_COMPILE_OPTIONS_IPO ${__lto_flags})
-
- set(CMAKE_${lang}_ARCHIVE_CREATE_IPO
-${CMAKE_GCC_AR} cr TARGET LINK_FLAGS OBJECTS
- )
-
- set(CMAKE_${lang}_ARCHIVE_APPEND_IPO
-${CMAKE_GCC_AR} r TARGET LINK_FLAGS OBJECTS
- )
-
- set(CMAKE_${lang}_ARCHIVE_FINISH_IPO
-${CMAKE_GCC_RANLIB} TARGET
- )
-endif()
- endif()
endmacro()
diff --git a/Source/cmMakefileLibraryTargetGenerator.cxx
b/Source/cmMakefileLibraryTargetGenerator.cxx
index 38d3c3c..d6a0cd4 100644
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx
@@ -140,7 +140,11 @@ void
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7724-g51a0501
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 51a0501c8ae25b7e4435a639fb4d25d3498e94d7 (commit)
via 9db9c1fc8b3314b70a243250ea2879c5a0e82799 (commit)
from a06c9465cf9c2dcc66a5b07327ecbe24ae667295 (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=51a0501c8ae25b7e4435a639fb4d25d3498e94d7
commit 51a0501c8ae25b7e4435a639fb4d25d3498e94d7
Merge: a06c946 9db9c1f
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Feb 14 07:56:29 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 14 07:56:29 2014 -0500
Merge topic 'INTERFACE-no-sources' into next
9db9c1fc cmTarget: Don't try to get sources of an INTERFACE_LIBRARY.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9db9c1fc8b3314b70a243250ea2879c5a0e82799
commit 9db9c1fc8b3314b70a243250ea2879c5a0e82799
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Feb 14 13:43:40 2014 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Feb 14 13:53:14 2014 +0100
cmTarget: Don't try to get sources of an INTERFACE_LIBRARY.
An an assert to ensure this.
diff --git a/Source/cmGeneratorTarget.cxx b/Source/cmGeneratorTarget.cxx
index 2573c85..175bb0e 100644
--- a/Source/cmGeneratorTarget.cxx
+++ b/Source/cmGeneratorTarget.cxx
@@ -498,11 +498,14 @@ cmTargetTraceDependencies
// Queue all the source files already specified for the target.
std::vectorcmSourceFile* sources;
- this-Target-GetSourceFiles(sources);
- for(std::vectorcmSourceFile*::const_iterator si = sources.begin();
- si != sources.end(); ++si)
+ if (this-Target-GetType() != cmTarget::INTERFACE_LIBRARY)
{
-this-QueueSource(*si);
+this-Target-GetSourceFiles(sources);
+for(std::vectorcmSourceFile*::const_iterator si = sources.begin();
+si != sources.end(); ++si)
+ {
+ this-QueueSource(*si);
+ }
}
// Queue pre-build, pre-link, and post-build rule dependencies.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index a61cab1..0c44681 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1468,7 +1468,8 @@ void cmGlobalGenerator::ComputeGeneratorTargetObjects()
for(cmGeneratorTargetsType::iterator ti = targets.begin();
ti != targets.end(); ++ti)
{
- if (ti-second-Target-IsImported())
+ if (ti-second-Target-IsImported()
+ || ti-second-Target-GetType() == cmTarget::INTERFACE_LIBRARY)
{
continue;
}
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 3e96b69..db34bd8 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -551,6 +551,7 @@ bool cmTarget::FindSourceFiles()
//
void cmTarget::GetSourceFiles(std::vectorcmSourceFile* files) const
{
+ assert(this-GetType() != INTERFACE_LIBRARY);
files = this-SourceFiles;
}
---
Summary of changes:
Source/cmGeneratorTarget.cxx | 11 +++
Source/cmGlobalGenerator.cxx |3 ++-
Source/cmTarget.cxx |1 +
3 files changed, 10 insertions(+), 5 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.12.2-1439-g66bf178
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 66bf178346e3f00f74a3d64eb00db48cedb0ffb6 (commit) from 945a66a5433aefea42cb624fd5e33c3e2316f39d (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=66bf178346e3f00f74a3d64eb00db48cedb0ffb6 commit 66bf178346e3f00f74a3d64eb00db48cedb0ffb6 Author: Kitware Robot kwro...@kitware.com AuthorDate: Sat Feb 15 00:01:11 2014 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sat Feb 15 00:01:11 2014 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 09075b1..5848568 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 12) -set(CMake_VERSION_TWEAK 20140214) +set(CMake_VERSION_TWEAK 20140215) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
