[cmake-developers] cmake build does too much work
I've been working on a project lately that isn't *that* massively large, but has an unusually high number of library and executable targets. One thing that's been bugging me is that any trivial change in a lower level library causes more than a hundred targets to be relinked, for no good reason I know of. Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. Does this sound like something CMake could/should do? (I'm thinking something like running objdump on the resulting library with suitable arguments and doing a copy_if_different on the output. I guess this would only apply to shared libraries, and probably should be an optional feature.) -- Matthew -- 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] cmake build does too much work
On 12/11/2013 5:13 PM, Matthew Woehlke wrote: I've been working on a project lately that isn't *that* massively large, but has an unusually high number of library and executable targets. One thing that's been bugging me is that any trivial change in a lower level library causes more than a hundred targets to be relinked, for no good reason I know of. Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. Does this sound like something CMake could/should do? (I'm thinking something like running objdump on the resulting library with suitable arguments and doing a copy_if_different on the output. I guess this would only apply to shared libraries, and probably should be an optional feature.) There is this property: http://www.cmake.org/cmake/help/git-master/variable/CMAKE_LINK_DEPENDS_NO_SHARED.html If you wanted to use that for your project I think you can just run cmake -DCMAKE_LINK_DEPENDS_NO_SHARED=TRUE. The other option sounds interesting but hard to implement in a cross platform manner. -Bill -- 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] cmake build does too much work
On 2013-12-11 17:40, Bill Hoffman wrote: On 12/11/2013 5:13 PM, Matthew Woehlke wrote: I've been working on a project lately that isn't *that* massively large, but has an unusually high number of library and executable targets. One thing that's been bugging me is that any trivial change in a lower level library causes more than a hundred targets to be relinked, for no good reason I know of. Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. Does this sound like something CMake could/should do? (I'm thinking something like running objdump on the resulting library with suitable arguments and doing a copy_if_different on the output. I guess this would only apply to shared libraries, and probably should be an optional feature.) There is this property: http://www.cmake.org/cmake/help/git-master/variable/CMAKE_LINK_DEPENDS_NO_SHARED.html Yes, but that can lead to a broken build if the ABI does change. (Hi, Stephen. I still oppose making the above on by default due to the possibility of broken builds. The difference here is that we are actually doing extra work in order to determine if a relink is necessary of if it is *safe* to skip it. IOW, I still choose correctness over performance; the difference is that the proposed technique would let us have both :-).) The other option sounds interesting but hard to implement in a cross platform manner. Agreed, but even if it only worked on some platforms it could be a significant benefit to them. It's the sort of feature that can just be ignored if not supported with no loss in correctness (only performance). Actually because of its .lib files I wonder if maybe Windows either already doesn't have this problem, or at least would be much easier to provide this feature there. (I'd be mainly interested in Linux.) Hmm, come to think of it, if this were to be implemented, I wonder if it is faster for the ABI stamp to be an actual dump of the ABI, or a checksum (e.g. md5 / sha256) of the ABI dump... The latter would trade the extra cost computing the checksum for I/O; not needing to write the ABI dump to disk at all if it can be read via a pipe, and then only needing to read and possibly write a few bytes for the 'stamp' file. Actually, I suppose the build tool could also do this, but then the benefit is only realized by users of that build tool. (On the other hand, all users of that build tool would realize the benefit, and not just users of CMake.) Still, this now feels worth cross-posting to ninja... -- Matthew -- 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] cmake build does too much work
On Thu, Dec 12, 2013 at 00:00:42 +0100, Stephen Kelly wrote: You opposed a sensible default for CMAKE_LINK_DEPENDS_NO_SHARED: https://www.mail-archive.com/cmake-developers@cmake.org/msg06169.html I continue to consider the default value of that to be a mistake. How would a relink be forced with the default of ON when the ABI does break? Would I need to invoke the targets manually? That sounds painful to me. --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] cmake build does too much work
On 2013-12-11 17:13, Matthew Woehlke wrote: I've been working on a project lately that isn't *that* massively large, but has an unusually high number of library and executable targets. One thing that's been bugging me is that any trivial change in a lower level library causes more than a hundred targets to be relinked, for no good reason I know of. Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. Does this sound like something CMake could/should do? (I'm thinking something like running objdump on the resulting library with suitable arguments and doing a copy_if_different on the output. I guess this would only apply to shared libraries, and probably should be an optional feature.) FYI, the ninja folks mentioned that GYP already does this for Linux/Mac/Win... maybe we (CMake) could borrow their work? -- Matthew -- 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] cmake build does too much work
On Wed, Dec 11, 2013 at 17:13:00 -0500, Matthew Woehlke wrote: Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. While the tool I posted in the other message is a possibility, how would you deal with inline functions changing? Same with template implementations? For example, when a Boost *header* changes, dependencies need to be recompiled to get the new inline code. Which build systems actually have that level of granularity? Does XCode or VS track external dependencies on the file level? I don't *think* make and ninja do so, since after a GCC upgrade, my trees don't all of a sudden do a full rebuild (and after upgrading from Fedora N to N+1, nuking build trees is usually on the menu due to new soversions of libraries shifting around; a simple rebuild misses this). --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] cmake build does too much work
On 2013-12-11 19:21, Ben Boeckel wrote: On Wed, Dec 11, 2013 at 17:13:00 -0500, Matthew Woehlke wrote: Now, I *do* get that relinking is good if the library ABI changes. However, that's not the case here, and I am wondering if it would be possible for CMake to generate an additional, intermediary step after library linking to somehow export a file representing the ABI of the library (with overwrite checks to not modify the file if the ABI has not changed), and to use *those*, rather than the actual libraries, as the dependencies for targets linking to the libraries. I think this could produce a significant speed-up for incremental builds in some cases, as it would allow the build to short-circuit the relink of many targets when it turns out a library's ABI has not changed. While the tool I posted in the other message is a possibility, how would you deal with inline functions changing? Same with template implementations? I don't think this is relevant? In these cases, a header is changing, which will (hopefully) lead to the source files using that header being rebuilt, which will cause the library to relink anyway. (And if the sources *aren't* rebuilt, I don't think relinking will help?) Whether or not the sources of library B have correct dependencies on the headers of library A is, I believe, orthogonal to this problem, which is *only* about link-level dependencies. IOW the only rule affected would be 'libb.so: liba.so'. Which build systems actually have that level of granularity? Does XCode or VS track external dependencies on the file level? I don't *think* make and ninja do so, since after a GCC upgrade, my trees don't all of a sudden do a full rebuild (and after upgrading from Fedora N to N+1, nuking build trees is usually on the menu due to new soversions of libraries shifting around; a simple rebuild misses this). I would expect the behavior for external dependencies would not change; they would either trigger rebuilds or not the same as they do currently. (Since of course we cannot rely on having 'ABI stamp files' for any external libraries...) I'm *mainly* having problems within a single CMake project, which is what this would affect. It might have some downstream effect due to fewer libraries within the project changing to trigger downstream rebuilds, but that would be more incidental. -- Matthew -- 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] cmake build does too much work
On Wed, Dec 11, 2013 at 19:38:21 -0500, Matthew Woehlke wrote: I don't think this is relevant? In these cases, a header is changing, which will (hopefully) lead to the source files using that header being rebuilt, which will cause the library to relink anyway. (And if the sources *aren't* rebuilt, I don't think relinking will help?) I'm concerned about this: (external) (internal) template.hpp -- A.cpp -- header.h ^^ || |\- liba.so | ^ | | \-- B.cpp -- libb.so Where template.hpp changes (testing with 2.8.12.1 shows that touching template.hpp triggers a rebuild with Ninja, but not Unix Makefiles), internal_header.h changes and A.cpp gets recompiled, liba.so relinked and libb.so skipped because the ABI hasn't changed. The problem is that if something inlined from template.hpp is incompatible with what B.cpp has inlined, things need recompiled. I don't know how other tools work, but Unix Makefiles are certainly popular enough that I'd like to see that this cannot cause problems first. Of course, the fix may be to have A.cpp depend on template.hpp directly. I don't know the cost of this in for the build or generate time (but possibly noticable with files which include a lot). I would expect the behavior for external dependencies would not change; they would either trigger rebuilds or not the same as they do currently. (Since of course we cannot rely on having 'ABI stamp files' for any external libraries...) Maybe the problem I was referencing was out-of-scope. I wonder if abi-compliance-checker handles mismatches between inlined symbols (mostly a problem outside of -fvisibility=hidden). --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] cmake build does too much work
On 12/11/2013 6:00 PM, Stephen Kelly wrote: You opposed a sensible default for CMAKE_LINK_DEPENDS_NO_SHARED: https://www.mail-archive.com/cmake-developers@cmake.org/msg06169.html I continue to consider the default value of that to be a mistake. I am on the fence with this one. It is always best to have an incremental build that you can trust. However, I have to think pretty hard to come up with a case where you could change an object size without changing a header file that would cause a relink anyway. I can come up with ways to do it, but you would almost have to try -Bill -- 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] depend.make
This test has been performed on Windows 7 SP1 (64bit) and using CMake 2.8.12.1
and VS2005 SP1.
Here is the source code used (which does not use the Boost library).
#include iostream
int main(int argc, char **argv)
{
std::cout Hello world std::endl;
return 0;
}
Here is the CMakeLists.txt used which find and include Boost.
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.11)
FIND_PACKAGE(Boost 1.47.0 COMPONENTS
program_options
system
regex
math_c99)
IF(Boost_FOUND)
SET(Boost_INCLUDE_DIRS
${Boost_INCLUDE_DIR}/boost/tr1/tr1
${Boost_INCLUDE_DIR})
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
ENDIF()
SET(_SOURCES
main.cpp
)
ADD_EXECUTABLE(Dummy
${_SOURCES}
)
TARGET_LINK_LIBRARIES(Dummy
${Boost_LIBRARIES}
)
This configuration compiles and links.
When building the target a depend.make file is generated. Viewing this file I
was surprised to discover that main.cpp.obj appears to depend on a number of
boost files. There are 1200 lines like there;
CMakeFiles\Dummy.dir\main.cpp.obj: ..\main.cpp
CMakeFiles\Dummy.dir\main.cpp.obj:
c:\Boost_r\1_47_0\include\boost-1_52\boost\aligned_storage.hpp
CMakeFiles\Dummy.dir\main.cpp.obj:
c:\Boost_r\1_47_0\include\boost-1_52\boost\array.hpp
CMakeFiles\Dummy.dir\main.cpp.obj:
c:\Boost_r\1_47_0\include\boost-1_52\boost\assert.hpp
Why does depend.make contain so many dependencies between main.cpp.obj and
boost headers?
--
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] depend.make
On 11.12.2013 12:53, Lars wrote:
Here is the source code used (which does not use the Boost library).
#include iostream
int main(int argc, char **argv)
{
std::cout Hello world std::endl;
return 0;
}
${Boost_INCLUDE_DIR}/boost/tr1/tr1 does seem to contain an iostream
header which your #include iostream probably picks up.
Maybe that further includes the other boost headers?
Nils
--
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] building 64bit and 32bit libraries from same source
Hi, I'm running on a 32bit Linux and I'd like to build from the same source, libraries complied and linked as 32bit and 64bit. They should be installed in /usr/lib and /usr/lib64. How do I go about and do that? Thanks, Jacob -- 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] building 64bit and 32bit libraries from same source
On Wed, Dec 11, 2013 at 11:44 PM, Jacob Avraham jacob.avra...@compass-eos.com wrote: Hi, I'm running on a 32bit Linux and I'd like to build from the same source, libraries complied and linked as 32bit and 64bit. They should be installed in /usr/lib and /usr/lib64. How do I go about and do that? Personally I've never tried to build a 64-bit app/lib on a 32-bit machine, only the other way around. Looking at the packages available for my favourite Linux distribution (ArchLinux) there doesn't seem to be a compiler that could go the way you want. It should be possible though, you just need to get your hands on a compiler: http://stackoverflow.com/questions/7582218/gcc-compile-a-64-bit-binary-on-32-bit-platform So, the easiest way in CMake would be to create different folders and then generate makefiles/ninjafiles/whatever with different CFLAGS settings. /M -- 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.1-6153-g5a1184b
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 5a1184bd28543d56e583e30e6509c891e2fa (commit)
via 179313cb370550a236daf25315a2f3eb2916b7bd (commit)
from 8de2b07c14c1e1a6d7fea6473be4c31b67f9088f (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=5a1184bd28543d56e583e30e6509c891e2fa
commit 5a1184bd28543d56e583e30e6509c891e2fa
Merge: 8de2b07 179313c
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 03:36:05 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 03:36:05 2013 -0500
Merge topic 'GenerateExportHeader-tests' into next
179313c std::getline.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=179313cb370550a236daf25315a2f3eb2916b7bd
commit 179313cb370550a236daf25315a2f3eb2916b7bd
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 09:35:30 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 09:35:30 2013 +0100
std::getline.
diff --git a/Tests/Module/GenerateExportHeader/exportheader_test.cpp
b/Tests/Module/GenerateExportHeader/exportheader_test.cpp
index ad6f351..d82d02e 100644
--- a/Tests/Module/GenerateExportHeader/exportheader_test.cpp
+++ b/Tests/Module/GenerateExportHeader/exportheader_test.cpp
@@ -37,8 +37,8 @@ void compare(const char* refName, const char* testName)
{
std::string refLine;
std::string testLine;
-getline(ref, refLine);
-getline(test, testLine);
+std::getline(ref, refLine);
+std::getline(test, testLine);
if (testLine.size() testLine[testLine.size()-1] == ' ')
{
testLine = testLine.substr(0, testLine.size() - 1);
---
Summary of changes:
.../GenerateExportHeader/exportheader_test.cpp |4 ++--
1 files changed, 2 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, next, updated. v2.8.12.1-6162-g18058d6
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 18058d64d5c6741c06b2416865096caedc2f43b6 (commit)
via da14b47fcbfca7bfdea1b0d00e43a0c5bd23ff90 (commit)
from 471fe9e519d8a0f7486cf9a5da615a1a5d34905e (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=18058d64d5c6741c06b2416865096caedc2f43b6
commit 18058d64d5c6741c06b2416865096caedc2f43b6
Merge: 471fe9e da14b47
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 06:51:02 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 06:51:02 2013 -0500
Merge topic 'GenerateExportHeader-tests' into next
da14b47 Add reference files for older compilers.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da14b47fcbfca7bfdea1b0d00e43a0c5bd23ff90
commit da14b47fcbfca7bfdea1b0d00e43a0c5bd23ff90
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 12:49:07 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 12:49:07 2013 +0100
Add reference files for older compilers.
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index dc1d7f2..864929b 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -186,6 +186,8 @@ add_executable(GenerateExportHeader exportheader_test.cpp)
target_link_libraries(GenerateExportHeader ${link_libraries})
if (WIN32)
set(_platform Win32)
+elseif(NOT USE_COMPILER_HIDDEN_VISIBILITY)
+ set(_platform Empty)
else()
set(_platform UNIX)
endif()
diff --git
a/Tests/Module/GenerateExportHeader/reference/Empty/libshared_export.h
b/Tests/Module/GenerateExportHeader/reference/Empty/libshared_export.h
new file mode 100644
index 000..b6749b2
--- /dev/null
+++ b/Tests/Module/GenerateExportHeader/reference/Empty/libshared_export.h
@@ -0,0 +1,41 @@
+
+#ifndef LIBSHARED_EXPORT_H
+#define LIBSHARED_EXPORT_H
+
+#ifdef LIBSHARED_STATIC_DEFINE
+# define LIBSHARED_EXPORT
+# define LIBSHARED_NO_EXPORT
+#else
+# ifndef LIBSHARED_EXPORT
+#ifdef libshared_EXPORTS
+/* We are building this library */
+# define LIBSHARED_EXPORT
+#else
+/* We are using this library */
+# define LIBSHARED_EXPORT
+#endif
+# endif
+
+# ifndef LIBSHARED_NO_EXPORT
+#define LIBSHARED_NO_EXPORT
+# endif
+#endif
+
+#ifndef LIBSHARED_DEPRECATED
+# define LIBSHARED_DEPRECATED
+#endif
+
+#ifndef LIBSHARED_DEPRECATED_EXPORT
+# define LIBSHARED_DEPRECATED_EXPORT LIBSHARED_EXPORT LIBSHARED_DEPRECATED
+#endif
+
+#ifndef LIBSHARED_DEPRECATED_NO_EXPORT
+# define LIBSHARED_DEPRECATED_NO_EXPORT LIBSHARED_NO_EXPORT
LIBSHARED_DEPRECATED
+#endif
+
+#define DEFINE_NO_DEPRECATED 0
+#if DEFINE_NO_DEPRECATED
+# define LIBSHARED_NO_DEPRECATED
+#endif
+
+#endif
diff --git
a/Tests/Module/GenerateExportHeader/reference/Empty/libstatic_export.h
b/Tests/Module/GenerateExportHeader/reference/Empty/libstatic_export.h
new file mode 100644
index 000..e8000e2
--- /dev/null
+++ b/Tests/Module/GenerateExportHeader/reference/Empty/libstatic_export.h
@@ -0,0 +1,41 @@
+
+#ifndef LIBSTATIC_EXPORT_H
+#define LIBSTATIC_EXPORT_H
+
+#ifdef LIBSTATIC_STATIC_DEFINE
+# define LIBSTATIC_EXPORT
+# define LIBSTATIC_NO_EXPORT
+#else
+# ifndef LIBSTATIC_EXPORT
+#ifdef libstatic_EXPORTS
+/* We are building this library */
+# define LIBSTATIC_EXPORT
+#else
+/* We are using this library */
+# define LIBSTATIC_EXPORT
+#endif
+# endif
+
+# ifndef LIBSTATIC_NO_EXPORT
+#define LIBSTATIC_NO_EXPORT
+# endif
+#endif
+
+#ifndef LIBSTATIC_DEPRECATED
+# define LIBSTATIC_DEPRECATED
+#endif
+
+#ifndef LIBSTATIC_DEPRECATED_EXPORT
+# define LIBSTATIC_DEPRECATED_EXPORT LIBSTATIC_EXPORT LIBSTATIC_DEPRECATED
+#endif
+
+#ifndef LIBSTATIC_DEPRECATED_NO_EXPORT
+# define LIBSTATIC_DEPRECATED_NO_EXPORT LIBSTATIC_NO_EXPORT
LIBSTATIC_DEPRECATED
+#endif
+
+#define DEFINE_NO_DEPRECATED 0
+#if DEFINE_NO_DEPRECATED
+# define LIBSTATIC_NO_DEPRECATED
+#endif
+
+#endif
---
Summary of changes:
Tests/Module/GenerateExportHeader/CMakeLists.txt |2 ++
.../reference/{Win32 = Empty}/libshared_export.h |6 +++---
.../reference/{Win32 = Empty}/libstatic_export.h |2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
copy Tests/Module/GenerateExportHeader/reference/{Win32 =
Empty}/libshared_export.h (83%)
copy Tests/Module/GenerateExportHeader/reference/{Win32 =
Empty}/libstatic_export.h (94%)
hooks/post-receive
--
CMake
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6164-g79cd32e
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 79cd32e502535af8d7f70de4f6480ad940969cfe (commit)
via 51953108900f3c2e7d0e6e748357e991f5314172 (commit)
from 18058d64d5c6741c06b2416865096caedc2f43b6 (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=79cd32e502535af8d7f70de4f6480ad940969cfe
commit 79cd32e502535af8d7f70de4f6480ad940969cfe
Merge: 18058d6 5195310
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 06:55:41 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 06:55:41 2013 -0500
Merge topic 'GenerateExportHeader-tests' into next
5195310 Add reference files for MinGW.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51953108900f3c2e7d0e6e748357e991f5314172
commit 51953108900f3c2e7d0e6e748357e991f5314172
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 12:55:05 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 12:55:05 2013 +0100
Add reference files for MinGW.
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index 864929b..3c0254e 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -185,7 +185,11 @@ add_executable(GenerateExportHeader exportheader_test.cpp)
target_link_libraries(GenerateExportHeader ${link_libraries})
if (WIN32)
- set(_platform Win32)
+ if(MSVC)
+set(_platform Win32)
+ else()
+set(_platform MinGW)
+ endif()
elseif(NOT USE_COMPILER_HIDDEN_VISIBILITY)
set(_platform Empty)
else()
diff --git
a/Tests/Module/GenerateExportHeader/reference/MinGW/libshared_export.h
b/Tests/Module/GenerateExportHeader/reference/MinGW/libshared_export.h
new file mode 100644
index 000..d376631
--- /dev/null
+++ b/Tests/Module/GenerateExportHeader/reference/MinGW/libshared_export.h
@@ -0,0 +1,41 @@
+
+#ifndef LIBSHARED_EXPORT_H
+#define LIBSHARED_EXPORT_H
+
+#ifdef LIBSHARED_STATIC_DEFINE
+# define LIBSHARED_EXPORT
+# define LIBSHARED_NO_EXPORT
+#else
+# ifndef LIBSHARED_EXPORT
+#ifdef libshared_EXPORTS
+/* We are building this library */
+# define LIBSHARED_EXPORT __declspec(dllexport)
+#else
+/* We are using this library */
+# define LIBSHARED_EXPORT __declspec(dllimport)
+#endif
+# endif
+
+# ifndef LIBSHARED_NO_EXPORT
+#define LIBSHARED_NO_EXPORT
+# endif
+#endif
+
+#ifndef LIBSHARED_DEPRECATED
+# define LIBSHARED_DEPRECATED __attribute__ ((__deprecated__))
+#endif
+
+#ifndef LIBSHARED_DEPRECATED_EXPORT
+# define LIBSHARED_DEPRECATED_EXPORT LIBSHARED_EXPORT LIBSHARED_DEPRECATED
+#endif
+
+#ifndef LIBSHARED_DEPRECATED_NO_EXPORT
+# define LIBSHARED_DEPRECATED_NO_EXPORT LIBSHARED_NO_EXPORT
LIBSHARED_DEPRECATED
+#endif
+
+#define DEFINE_NO_DEPRECATED 0
+#if DEFINE_NO_DEPRECATED
+# define LIBSHARED_NO_DEPRECATED
+#endif
+
+#endif
diff --git
a/Tests/Module/GenerateExportHeader/reference/MinGW/libstatic_export.h
b/Tests/Module/GenerateExportHeader/reference/MinGW/libstatic_export.h
new file mode 100644
index 000..fd021e9
--- /dev/null
+++ b/Tests/Module/GenerateExportHeader/reference/MinGW/libstatic_export.h
@@ -0,0 +1,41 @@
+
+#ifndef LIBSTATIC_EXPORT_H
+#define LIBSTATIC_EXPORT_H
+
+#ifdef LIBSTATIC_STATIC_DEFINE
+# define LIBSTATIC_EXPORT
+# define LIBSTATIC_NO_EXPORT
+#else
+# ifndef LIBSTATIC_EXPORT
+#ifdef libstatic_EXPORTS
+/* We are building this library */
+# define LIBSTATIC_EXPORT
+#else
+/* We are using this library */
+# define LIBSTATIC_EXPORT
+#endif
+# endif
+
+# ifndef LIBSTATIC_NO_EXPORT
+#define LIBSTATIC_NO_EXPORT
+# endif
+#endif
+
+#ifndef LIBSTATIC_DEPRECATED
+# define LIBSTATIC_DEPRECATED __attribute__ ((__deprecated__))
+#endif
+
+#ifndef LIBSTATIC_DEPRECATED_EXPORT
+# define LIBSTATIC_DEPRECATED_EXPORT LIBSTATIC_EXPORT LIBSTATIC_DEPRECATED
+#endif
+
+#ifndef LIBSTATIC_DEPRECATED_NO_EXPORT
+# define LIBSTATIC_DEPRECATED_NO_EXPORT LIBSTATIC_NO_EXPORT
LIBSTATIC_DEPRECATED
+#endif
+
+#define DEFINE_NO_DEPRECATED 0
+#if DEFINE_NO_DEPRECATED
+# define LIBSTATIC_NO_DEPRECATED
+#endif
+
+#endif
---
Summary of changes:
Tests/Module/GenerateExportHeader/CMakeLists.txt |6 +-
.../reference/{Win32 = MinGW}/libshared_export.h |2 +-
.../reference/{UNIX = MinGW}/libstatic_export.h |0
3 files changed, 6 insertions(+), 2 deletions(-)
copy Tests/Module/GenerateExportHeader/reference/{Win32 =
MinGW}/libshared_export.h
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6166-g1cf1d65
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 1cf1d65a919d3e2d66393c04ffb1e8dd3d54e1fb (commit)
via aa1e89caf70c59548b023426c6b003f818cbb750 (commit)
from 79cd32e502535af8d7f70de4f6480ad940969cfe (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=1cf1d65a919d3e2d66393c04ffb1e8dd3d54e1fb
commit 1cf1d65a919d3e2d66393c04ffb1e8dd3d54e1fb
Merge: 79cd32e aa1e89c
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 07:00:39 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 07:00:39 2013 -0500
Merge topic 'GenerateExportHeader-tests' into next
aa1e89c Try to fix on MSVC6.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aa1e89caf70c59548b023426c6b003f818cbb750
commit aa1e89caf70c59548b023426c6b003f818cbb750
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 13:00:04 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 13:00:04 2013 +0100
Try to fix on MSVC6.
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index 3c0254e..9ce44fa 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -197,6 +197,6 @@ else()
endif()
target_compile_definitions(GenerateExportHeader
PRIVATE
-SRC_DIR=${CMAKE_CURRENT_SOURCE_DIR}/reference/${_platform}
-BIN_DIR=${CMAKE_CURRENT_BINARY_DIR}
+SRC_DIR=${CMAKE_CURRENT_SOURCE_DIR}/reference/${_platform}
+BIN_DIR=${CMAKE_CURRENT_BINARY_DIR}
)
diff --git a/Tests/Module/GenerateExportHeader/exportheader_test.cpp
b/Tests/Module/GenerateExportHeader/exportheader_test.cpp
index d82d02e..e5f30fa 100644
--- a/Tests/Module/GenerateExportHeader/exportheader_test.cpp
+++ b/Tests/Module/GenerateExportHeader/exportheader_test.cpp
@@ -124,10 +124,13 @@ int main()
libstatic_not_exported();
libstatic_excluded();
- compare(SRC_DIR /libshared_export.h,
- BIN_DIR /libshared/libshared_export.h);
- compare(SRC_DIR /libstatic_export.h,
- BIN_DIR /libstatic/libstatic_export.h);
+#define STRINGIFY_IMPL(A) #A
+#define STRINGIFY(A) STRINGIFY_IMPL(A)
+
+ compare(STRINGIFY(SRC_DIR) /libshared_export.h,
+ STRINGIFY(BIN_DIR) /libshared/libshared_export.h);
+ compare(STRINGIFY(SRC_DIR) /libstatic_export.h,
+ STRINGIFY(BIN_DIR) /libstatic/libstatic_export.h);
return 0;
}
---
Summary of changes:
Tests/Module/GenerateExportHeader/CMakeLists.txt |4 ++--
.../GenerateExportHeader/exportheader_test.cpp | 11 +++
2 files changed, 9 insertions(+), 6 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.12.1-6174-g15c47f1
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 15c47f1df7f99c615a644b456815949a3ea835ca (commit)
via 1c8994a2f6b44ed4528bba7ebe759bd2bf06ba97 (commit)
via 689ce90335bce8e92b14c91678a50a6a6f8863fb (commit)
via ad0dea52f79deab6a6f8a9f237ad1668fe547169 (commit)
via fea4dfe2475182f69ab6ee3550ca834426df453b (commit)
via 2004f998af19e3cb8d9c23ec947a8d0ad8e44aad (commit)
from 2be0d495487785c47e4d235c8f3bb306636709bc (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=15c47f1df7f99c615a644b456815949a3ea835ca
commit 15c47f1df7f99c615a644b456815949a3ea835ca
Merge: 2be0d49 1c8994a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 07:37:49 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 07:37:49 2013 -0500
Merge topic 'constify' into next
1c8994a Constify autogen handling.
689ce90 Autogen: Split AutoRcc handling into two methods
ad0dea5 cmLocalGenerator: Constify target definitions access
fea4dfe Constify cmGeneratorTarget access.
2004f99 Constify handling of link targets.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c8994a2f6b44ed4528bba7ebe759bd2bf06ba97
commit 1c8994a2f6b44ed4528bba7ebe759bd2bf06ba97
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Dec 10 15:45:27 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 13:37:07 2013 +0100
Constify autogen handling.
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index b7bc475..f60d24d 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -334,7 +334,8 @@ protected:
virtual bool CheckALLOW_DUPLICATE_CUSTOM_TARGETS();
bool CheckTargets();
- typedef std::vectorstd::paircmQtAutoGenerators, cmTarget* AutogensType;
+ typedef std::vectorstd::paircmQtAutoGenerators,
+cmTarget const* AutogensType;
void CreateQtAutoGeneratorsTargets(AutogensType autogens);
std::string SelectMakeProgram(const char* makeProgram,
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 1988c5d..2b4bb8a 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -138,14 +138,14 @@ cmQtAutoGenerators::cmQtAutoGenerators()
}
}
-static std::string getAutogenTargetName(cmTarget *target)
+static std::string getAutogenTargetName(cmTarget const* target)
{
std::string autogenTargetName = target-GetName();
autogenTargetName += _automoc;
return autogenTargetName;
}
-static std::string getAutogenTargetDir(cmTarget *target)
+static std::string getAutogenTargetDir(cmTarget const* target)
{
cmMakefile* makefile = target-GetMakefile();
std::string targetDir = makefile-GetCurrentOutputDirectory();
@@ -296,7 +296,7 @@ bool cmQtAutoGenerators::InitializeAutogenTarget(cmTarget*
target)
return true;
}
-static void GetCompileDefinitionsAndDirectories(cmTarget *target,
+static void GetCompileDefinitionsAndDirectories(cmTarget const* target,
const char * config,
std::string incs,
std::string defs)
@@ -304,10 +304,12 @@ static void GetCompileDefinitionsAndDirectories(cmTarget
*target,
cmMakefile* makefile = target-GetMakefile();
cmLocalGenerator* localGen = makefile-GetLocalGenerator();
std::vectorstd::string includeDirs;
- cmGeneratorTarget gtgt(target);
+ cmGeneratorTarget *gtgt = target-GetMakefile()-GetLocalGenerator()
+ -GetGlobalGenerator()
+ -GetGeneratorTarget(target);
// Get the include dirs for this target, without stripping the implicit
// include dirs off, see http://public.kitware.com/Bug/view.php?id=13667
- localGen-GetIncludeDirectories(includeDirs, gtgt, CXX, config, false);
+ localGen-GetIncludeDirectories(includeDirs, gtgt, CXX, config, false);
const char* sep = ;
incs = ;
for(std::vectorstd::string::const_iterator incDirIt = includeDirs.begin();
@@ -333,7 +335,7 @@ static void GetCompileDefinitionsAndDirectories(cmTarget
*target,
}
}
-void cmQtAutoGenerators::SetupAutoGenerateTarget(cmTarget* target)
+void cmQtAutoGenerators::SetupAutoGenerateTarget(cmTarget const* target)
{
cmMakefile* makefile = target-GetMakefile();
@@ -436,7 +438,7 @@ void cmQtAutoGenerators::SetupAutoGenerateTarget(cmTarget*
target)
}
}
-void cmQtAutoGenerators::SetupAutoMocTarget(cmTarget* target,
+void
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6176-g31cd2c0
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 31cd2c0af0a2cc0c891bdfa9b673d263685cac7c (commit)
via 6123a737fc7dd612d17682ba8a09b2ada538d37a (commit)
from 15c47f1df7f99c615a644b456815949a3ea835ca (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=31cd2c0af0a2cc0c891bdfa9b673d263685cac7c
commit 31cd2c0af0a2cc0c891bdfa9b673d263685cac7c
Merge: 15c47f1 6123a73
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 08:03:50 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 08:03:50 2013 -0500
Merge topic 'GenerateExportHeader-tests' into next
6123a73 Add information message.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6123a737fc7dd612d17682ba8a09b2ada538d37a
commit 6123a737fc7dd612d17682ba8a09b2ada538d37a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 14:03:10 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 14:03:10 2013 +0100
Add information message.
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index 9ce44fa..3540f16 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -195,6 +195,7 @@ elseif(NOT USE_COMPILER_HIDDEN_VISIBILITY)
else()
set(_platform UNIX)
endif()
+message( Testing reference: ${_platform})
target_compile_definitions(GenerateExportHeader
PRIVATE
SRC_DIR=${CMAKE_CURRENT_SOURCE_DIR}/reference/${_platform}
---
Summary of changes:
Tests/Module/GenerateExportHeader/CMakeLists.txt |1 +
1 files changed, 1 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, next, updated. v2.8.12.1-6181-g8cb8b3b
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 8cb8b3b62ad3072c00dac34559c3e1851b4a46ca (commit) via 62c276f03ef1c8c1c94c885cf2bcf3771f64ec35 (commit) from 2f6589ebc298f1eca198dd6b18b9657e7cd2646f (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=8cb8b3b62ad3072c00dac34559c3e1851b4a46ca commit 8cb8b3b62ad3072c00dac34559c3e1851b4a46ca Merge: 2f6589e 62c276f Author: Daniele E. Domenichelli daniele.domeniche...@gmail.com AuthorDate: Wed Dec 11 08:10:53 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Dec 11 08:10:53 2013 -0500 Merge topic 'FindSubversion-TortoiseSVN' into next 62c276f FindSubversion: Use TortoiseSVN registry key to locate svn http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=62c276f03ef1c8c1c94c885cf2bcf3771f64ec35 commit 62c276f03ef1c8c1c94c885cf2bcf3771f64ec35 Author: Daniele E. Domenichelli daniele.domeniche...@iit.it AuthorDate: Wed Dec 11 13:59:44 2013 +0100 Commit: Daniele E. Domenichelli daniele.domeniche...@iit.it CommitDate: Wed Dec 11 13:59:48 2013 +0100 FindSubversion: Use TortoiseSVN registry key to locate svn If TortoiseSVN is not installed in the default path, the svn executable installed by TortoiseSVN is not found. Using the registry key should always find it. diff --git a/Modules/FindSubversion.cmake b/Modules/FindSubversion.cmake index 2338721..0d13318 100644 --- a/Modules/FindSubversion.cmake +++ b/Modules/FindSubversion.cmake @@ -73,6 +73,8 @@ # License text for the above reference.) find_program(Subversion_SVN_EXECUTABLE svn + PATHS +[HKEY_LOCAL_MACHINE\\Software\\TortoiseSVN;Directory]/bin DOC subversion command line client) mark_as_advanced(Subversion_SVN_EXECUTABLE) --- Summary of changes: Modules/FindSubversion.cmake |2 ++ 1 files changed, 2 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, next, updated. v2.8.12.1-6179-g2f6589e
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 2f6589ebc298f1eca198dd6b18b9657e7cd2646f (commit)
via 618e67b60fe3bb559aa40b628eed225c4f4b9d39 (commit)
via 62b90453d701d655cc53b0cda4c9d3d800fefa26 (commit)
from 31cd2c0af0a2cc0c891bdfa9b673d263685cac7c (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=2f6589ebc298f1eca198dd6b18b9657e7cd2646f
commit 2f6589ebc298f1eca198dd6b18b9657e7cd2646f
Merge: 31cd2c0 618e67b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 08:10:04 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 08:10:04 2013 -0500
Merge topic 'minor-cleanup' into next
618e67b Avoid certain actions on IMPORTED targets.
62b9045 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=618e67b60fe3bb559aa40b628eed225c4f4b9d39
commit 618e67b60fe3bb559aa40b628eed225c4f4b9d39
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Nov 29 13:18:24 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 14:07:55 2013 +0100
Avoid certain actions on IMPORTED targets.
As we're iterating over IMPORTED targets now, handle them in
the loop body. The existing behavior is harmless because generally
nothing is done anyway for IMPORTED targets in these code paths,
because they do not have sources for example.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index e6f3d94..83281ce 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1379,6 +1379,10 @@ void cmGlobalGenerator::ComputeGeneratorTargetObjects()
for(cmGeneratorTargetsType::iterator ti = targets.begin();
ti != targets.end(); ++ti)
{
+ if (ti-second-Target-IsImported())
+{
+continue;
+}
cmGeneratorTarget* gt = ti-second;
gt-ClassifySources();
gt-LookupObjectLibraries();
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index c3c5299..5892105 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -261,6 +261,10 @@ void cmLocalGenerator::TraceDependencies()
for(cmGeneratorTargetsType::iterator t = targets.begin();
t != targets.end(); ++t)
{
+if (ti-second-Target-IsImported())
+ {
+ continue;
+ }
t-second-TraceDependencies();
}
}
@@ -545,6 +549,10 @@ void cmLocalGenerator::GenerateTargetManifest()
{
continue;
}
+if (target-Target-IsImported())
+ {
+ continue;
+ }
if(configNames.empty())
{
target.GenerateTargetManifest(0);
---
Summary of changes:
Source/CMakeVersion.cmake|2 +-
Source/cmGlobalGenerator.cxx |4
Source/cmLocalGenerator.cxx |8
3 files changed, 13 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.12.1-6183-g3755dab
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 3755dab985d601d18120c6d4d01e2062c027788c (commit)
via 4e2a72b43775f60ce0c85b71109ea8b1213a8896 (commit)
from 8cb8b3b62ad3072c00dac34559c3e1851b4a46ca (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=3755dab985d601d18120c6d4d01e2062c027788c
commit 3755dab985d601d18120c6d4d01e2062c027788c
Merge: 8cb8b3b 4e2a72b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 08:22:44 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 08:22:44 2013 -0500
Merge topic 'minor-cleanup' into next
4e2a72b Fix build.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4e2a72b43775f60ce0c85b71109ea8b1213a8896
commit 4e2a72b43775f60ce0c85b71109ea8b1213a8896
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 14:21:02 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 14:21:46 2013 +0100
Fix build.
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 5892105..0845120 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -261,7 +261,7 @@ void cmLocalGenerator::TraceDependencies()
for(cmGeneratorTargetsType::iterator t = targets.begin();
t != targets.end(); ++t)
{
-if (ti-second-Target-IsImported())
+if (t-second-Target-IsImported())
{
continue;
}
@@ -549,7 +549,7 @@ void cmLocalGenerator::GenerateTargetManifest()
{
continue;
}
-if (target-Target-IsImported())
+if (target.Target-IsImported())
{
continue;
}
---
Summary of changes:
Source/cmLocalGenerator.cxx |4 ++--
1 files changed, 2 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, next, updated. v2.8.12.1-6185-gf97d707
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 f97d707d546b9e6059a982ba301a9a00b9469ac1 (commit)
via 41e48c45e8069ea551ab8511457fd712f5b3b89b (commit)
from 3755dab985d601d18120c6d4d01e2062c027788c (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=f97d707d546b9e6059a982ba301a9a00b9469ac1
commit f97d707d546b9e6059a982ba301a9a00b9469ac1
Merge: 3755dab 41e48c4
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 08:23:56 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 08:23:56 2013 -0500
Merge topic 'minor-cleanup' into next
41e48c4 Avoid certain actions on IMPORTED targets.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41e48c45e8069ea551ab8511457fd712f5b3b89b
commit 41e48c45e8069ea551ab8511457fd712f5b3b89b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Nov 29 13:18:24 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 14:23:09 2013 +0100
Avoid certain actions on IMPORTED targets.
As we're iterating over IMPORTED targets now, handle them in
the loop body. The existing behavior is harmless because generally
nothing is done anyway for IMPORTED targets in these code paths,
because they do not have sources for example.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index e6f3d94..83281ce 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1379,6 +1379,10 @@ void cmGlobalGenerator::ComputeGeneratorTargetObjects()
for(cmGeneratorTargetsType::iterator ti = targets.begin();
ti != targets.end(); ++ti)
{
+ if (ti-second-Target-IsImported())
+{
+continue;
+}
cmGeneratorTarget* gt = ti-second;
gt-ClassifySources();
gt-LookupObjectLibraries();
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index c3c5299..0845120 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -261,6 +261,10 @@ void cmLocalGenerator::TraceDependencies()
for(cmGeneratorTargetsType::iterator t = targets.begin();
t != targets.end(); ++t)
{
+if (t-second-Target-IsImported())
+ {
+ continue;
+ }
t-second-TraceDependencies();
}
}
@@ -545,6 +549,10 @@ void cmLocalGenerator::GenerateTargetManifest()
{
continue;
}
+if (target.Target-IsImported())
+ {
+ continue;
+ }
if(configNames.empty())
{
target.GenerateTargetManifest(0);
---
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, next, updated. v2.8.12.1-6187-g078b0ed
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 078b0edad55cbea17be0156df393bbc9e8a38860 (commit)
via ae89ccaeeb2102c1265d5dd821ffaca0c3a63782 (commit)
from f97d707d546b9e6059a982ba301a9a00b9469ac1 (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=078b0edad55cbea17be0156df393bbc9e8a38860
commit 078b0edad55cbea17be0156df393bbc9e8a38860
Merge: f97d707 ae89cca
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 09:30:00 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 09:30:00 2013 -0500
Merge topic 'constify' into next
ae89cca Visual Studio fix.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae89ccaeeb2102c1265d5dd821ffaca0c3a63782
commit ae89ccaeeb2102c1265d5dd821ffaca0c3a63782
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 15:10:41 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 15:29:02 2013 +0100
Visual Studio fix.
diff --git a/Source/cmGlobalVisualStudio71Generator.cxx
b/Source/cmGlobalVisualStudio71Generator.cxx
index 61d3c4c..6cfad25 100644
--- a/Source/cmGlobalVisualStudio71Generator.cxx
+++ b/Source/cmGlobalVisualStudio71Generator.cxx
@@ -157,7 +157,7 @@ void
cmGlobalVisualStudio71Generator::WriteProject(std::ostream fout,
const char* dspname,
const char* dir,
- cmTarget t)
+ cmTarget const t)
{
// check to see if this is a fortran build
const char* ext = .vcproj;
@@ -209,7 +209,7 @@ void
cmGlobalVisualStudio71Generator
::WriteProjectDepends(std::ostream fout,
const char*,
- const char*, cmTarget target)
+ const char*, cmTarget const target)
{
VSDependSet const depends = this-VSTargetDepends[target];
for(VSDependSet::const_iterator di = depends.begin();
diff --git a/Source/cmGlobalVisualStudio71Generator.h
b/Source/cmGlobalVisualStudio71Generator.h
index e136db7..04e3a55 100644
--- a/Source/cmGlobalVisualStudio71Generator.h
+++ b/Source/cmGlobalVisualStudio71Generator.h
@@ -59,9 +59,11 @@ protected:
std::vectorcmLocalGenerator* generators);
virtual void WriteSolutionConfigurations(std::ostream fout);
virtual void WriteProject(std::ostream fout,
-const char* name, const char* path, cmTarget t);
+const char* name, const char* path,
+cmTarget const t);
virtual void WriteProjectDepends(std::ostream fout,
- const char* name, const char* path, cmTarget t);
+ const char* name, const char* path,
+ cmTarget const t);
virtual void WriteProjectConfigurations(
std::ostream fout, const char* name, cmTarget::TargetType type,
const std::setstd::string configsPartOfDefaultBuild,
diff --git a/Source/cmGlobalVisualStudio8Generator.cxx
b/Source/cmGlobalVisualStudio8Generator.cxx
index e4ce13f..12c240b 100644
--- a/Source/cmGlobalVisualStudio8Generator.cxx
+++ b/Source/cmGlobalVisualStudio8Generator.cxx
@@ -415,7 +415,7 @@ bool cmGlobalVisualStudio8Generator::ComputeTargetDepends()
//
void cmGlobalVisualStudio8Generator::WriteProjectDepends(
- std::ostream fout, const char*, const char*, cmTarget t)
+ std::ostream fout, const char*, const char*, cmTarget const t)
{
TargetDependSet const unordered = this-GetTargetDirectDepends(t);
OrderedTargetDependSet depends(unordered);
diff --git a/Source/cmGlobalVisualStudio8Generator.h
b/Source/cmGlobalVisualStudio8Generator.h
index ad01a24..5b952c4 100644
--- a/Source/cmGlobalVisualStudio8Generator.h
+++ b/Source/cmGlobalVisualStudio8Generator.h
@@ -84,7 +84,7 @@ protected:
const char* platformMapping = NULL);
virtual bool ComputeTargetDepends();
virtual void WriteProjectDepends(std::ostream fout, const char* name,
- const char* path, cmTarget t);
+ const char* path, cmTarget const t);
std::string Name;
std::string WindowsCEVersion;
---
Summary of changes:
Source/cmGlobalVisualStudio71Generator.cxx |4 ++--
Source/cmGlobalVisualStudio71Generator.h |6 --
Source/cmGlobalVisualStudio8Generator.cxx |2 +-
[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6196-g53e3e97
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 53e3e97c7e7e206922f517930fc76e0b870c04c7 (commit)
via 0edc02afa3b835bd75d912cb689b169c18fb6e3a (commit)
from 7cdb41bf154e08726d8e63a0c6e1ef8870b10161 (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=53e3e97c7e7e206922f517930fc76e0b870c04c7
commit 53e3e97c7e7e206922f517930fc76e0b870c04c7
Merge: 7cdb41b 0edc02a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 09:33:39 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Dec 11 09:33:39 2013 -0500
Merge topic 'GenerateExportHeader-tests' into next
0edc02a Fix Borland.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0edc02afa3b835bd75d912cb689b169c18fb6e3a
commit 0edc02afa3b835bd75d912cb689b169c18fb6e3a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Dec 11 15:32:36 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Dec 11 15:32:36 2013 +0100
Fix Borland.
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index 3540f16..b98b54a 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -187,8 +187,10 @@ target_link_libraries(GenerateExportHeader
${link_libraries})
if (WIN32)
if(MSVC)
set(_platform Win32)
- else()
+ elseif(MINGW)
set(_platform MinGW)
+ else()
+set(_platform Empty)
endif()
elseif(NOT USE_COMPILER_HIDDEN_VISIBILITY)
set(_platform Empty)
---
Summary of changes:
Tests/Module/GenerateExportHeader/CMakeLists.txt |4 +++-
1 files changed, 3 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
