[cmake-developers] cmake build does too much work

2013-12-11 Thread Matthew Woehlke
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Bill Hoffman
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Matthew Woehlke
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Ben Boeckel
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Matthew Woehlke
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Ben Boeckel
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

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Matthew Woehlke
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,

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Ben Boeckel
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*

Re: [cmake-developers] cmake build does too much work

2013-12-11 Thread Bill Hoffman
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

[CMake] depend.make

2013-12-11 Thread Lars
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

Re: [CMake] depend.make

2013-12-11 Thread Nils Gladitz
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

[CMake] building 64bit and 32bit libraries from same source

2013-12-11 Thread Jacob Avraham
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

Re: [CMake] building 64bit and 32bit libraries from same source

2013-12-11 Thread Magnus Therning
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6153-g5a1184b

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6162-g18058d6

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6164-g79cd32e

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6166-g1cf1d65

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6174-g15c47f1

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6176-g31cd2c0

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6181-g8cb8b3b

2013-12-11 Thread Daniele E . Domenichelli
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6179-g2f6589e

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6183-g3755dab

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6185-gf97d707

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6187-g078b0ed

2013-12-11 Thread Stephen Kelly
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

[Cmake-commits] CMake branch, next, updated. v2.8.12.1-6196-g53e3e97

2013-12-11 Thread Stephen Kelly
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