The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13950
==
Reported By:Michael Riss
Assigned To:
On 02/23/2013 07:35 AM, Stephen Kelly wrote:
As TARGET_DEFINED is not used in cmake now, I was considering removing it.
If we remove it we'll have more freedom in the future to define it again if
it is needed, or to define a similar expression with semantics we need.
Currently the
On 02/24/2013 10:29 AM, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default.
For reference, it was introduced in this thread:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13951
==
Reported By:ITF-EDV Fröschl GmbH
Assigned To:
Brad King wrote:
If the option were to be on by default then instead there
should be the reverse option off by default with a name like:
CMAKE_LINK_DEPENDS_SHARED_LIBRARIES
I implemented that but one of the dashboards already fails:
On 02/25/2013 11:46 AM, Stephen Kelly wrote:
Brad King wrote:
If the option were to be on by default then instead there
should be the reverse option off by default with a name like:
CMAKE_LINK_DEPENDS_SHARED_LIBRARIES
I implemented that but one of the dashboards already fails:
On 02/25/2013 01:29 PM, Matthew Woehlke wrote:
On 2013-02-24 10:29, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default. Is there any reason not
to enable it by default?
What is the use case for this?
On Monday 25 February 2013, Brad King wrote:
On 02/24/2013 10:29 AM, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default.
For reference, it was introduced in this thread:
On 02/25/2013 02:18 PM, Alexander Neundorf wrote:
It is a change in default behavior.
Maybe with a policy ?
How would it trigger? We can't warn on every target that links
to a shared library. We're not changing any existing interfaces.
The behavior only affects the dependencies placed in
On Monday 25 February 2013, Brad King wrote:
On 02/25/2013 02:18 PM, Alexander Neundorf wrote:
It is a change in default behavior.
Maybe with a policy ?
How would it trigger? We can't warn on every target that links
to a shared library. We're not changing any existing interfaces.
if
On 2013-02-25 14:00, Brad King wrote:
On 02/25/2013 01:29 PM, Matthew Woehlke wrote:
On 2013-02-24 10:29, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default. Is there any reason not
to enable it by
On 02/25/2013 02:56 PM, Matthew Woehlke wrote:
I guess my personal opinion is that I can think of enough theoretical
ways where a relink might be needed, and haven't encountered a project
where the relink cost is sufficiently high, to feel that I would
personally want to not relink.
You've
Can you elaborate on some of the theoretical cases where relinking
will be needed but no header files have changed? It would be useful
to have them available for discussion.
I can think of one, but it’s probably not that common:
A header file declares a function prototype, but there is
On 2013-02-25 15:02, Brad King wrote:
Can you elaborate on some of the theoretical cases where relinking
will be needed but no header files have changed? It would be useful
to have them available for discussion.
The possibility that first came to mind is where the API depends on
compiler
Brad King wrote:
On 02/25/2013 03:09 PM, dlrd...@aol.com wrote:
Can you elaborate on some of the theoretical cases where relinking
will be needed but no header files have changed? It would be useful
to have them available for discussion.
I can think of one, but it’s probably not that
On 2/25/2013 5:18 PM, Matthew Woehlke wrote:
The possibility that first came to mind is where the API depends on
compiler flags or similar preprocessor-ish bits, especially if these are
not well guarded with something like a configured config.h to change
when these change (and ensure that
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=13952
==
Reported By:Timo R.
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13953
==
Reported By:mseise
Assigned To:
Am Sonntag, 24. Februar 2013 um 19:58:53, schrieb David Brown
cypher...@gmail.com
I'm trying to patch and build a Makefile-based project using the
ExternalProject module. My patch command looks like this:
PATCH_COMMAND patch -p1 -t -N
${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch
When
David Brown wrote:
I'm trying to patch and build a Makefile-based project using the
ExternalProject module. My patch command looks like this:
PATCH_COMMAND patch -p1 -t -N
${CMAKE_CURRENT_SOURCE_DIR}/IntelDFP.patch
When building, however, I get this:
[ 10%] Performing patch
Hello everyone,
This is certainly a known issue but I coulnd't find anything related to
this needs on internet :
I got :
an executable EX, a static library B and a static library C with cross
dependencies :
libB depends on libC and libC depends on libB.
EX depends on libB
If I write :
libB depends on libC and libC depends on libB.
How is that even possible? You compile B and it fails because there's no C
yet. You compile C and it fails because there's no B yet.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Well it is indeed possible and it works... Note that static libraries 's
object files are built with unresolved symbols. Final resolution is
performed when building executable
Therefore libB can compile without libC and conversely ...
Anyone else ?
On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš
Hello Pierre,
my knowledge concerning the linking process is rather limited, but wouldn't
that mean you don't need to inter-link the libraries at all, when the symbols
are resolved at link-time with the executable?
add_executable(ex1 libB libC1 libC2) should suffice then.
Best regards,
Andreas
I think you shouldn't make B depend on anything, and just make sure that you
list all the libs you need at executable link time.
Sent from my iPhone
On Feb 25, 2013, at 7:47, Pierre Mallard mallard.pie...@gmail.com wrote:
Well it is indeed possible and it works... Note that static libraries
Hello Pierre,
self reply as a correction, sorry:
what I meant was that only linking the executables
TARGET_LINK_LIBRARIES(EX1 libB libC1)
TARGET_LINK_LIBRARIES(EX2 libB libC2)
should suffice.
Andreas
Am 25.02.2013 um 14:14 schrieb Andreas Stahl:
Hello Pierre,
my knowledge concerning the
Hi everyone,
Reading answer from leif and andreas, leads me to advance a bit.
To my opinion writing target_link_libraries(exe1 libB libC) would certainly
works (but I m not able to test it at the moment).
But my problem should be explain the more tricky way :
libB depends on libC function
I see. I would not try to express this complexity to cmake. Is there a way you
can separate the alternate functionality out of C so that it doesn't cause the
dependency graph to fragment this way? Usually circular dependencies mean you
need to refactor something anyway. If you can make the dep
Surely I can refactor code to avoid cross-dependencies...
But the problem is more on the definition of the target link line at
executable level than on cross dependency.
Indeed even if C does not depends on B, or in your example X, writing
TARGET_LINK_LIBRARIES(EX1 libD libX1)
would always leads
Martin Koller wrote:
On Saturday 23 February 2013 14:58:11 Rolf Eike Beer wrote:
Martin Koller wrote:
On Friday 22 February 2013 12:23:23 Koller, Martin wrote:
I propose the attached patch for CMakeDetermineSystem.cmake
Can someone add this to the mentioned mantis bug entry or shall
Shall I force the compiler?
This is all I can find on the CMake Cross Compiling wiki: If your
compiler is not able to build a simple program by default without special
flags or files (e.g. linker scripts or memory layout files), the toolchain
file as shown above doesn't work. Then you have to
Hello,
i've set CTEST_UPDATE_OPTIONS as followed:
set(CTEST_UPDATE_OPTIONS --tags)
I set this, because I need newely created and/or modified tags.
When I set this option then I get the error:
git.cmd fetch --tags Update command failed
Is there an other way of doing so?
Thanks in advance
On Sunday 24 February 2013, Chris Stankevitz wrote:
On Sun, Feb 24, 2013 at 12:37 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
github links:
https://github.com/chrisstankevitz/hello
https://github.com/chrisstankevitz/hello-client
Maybe we'll start with the old way and get
Hello again,
CTEST_UPDATE_COMMAND is set to ${GIT_EXECUTABLE}.
I also tried to extend the CTEST_CHECKOUT_COMMAND variable, but here I get also
an error.
Please, could someone help?
Thanks in advance
Am 25.02.2013 um 18:15 schrieb NoRulez noru...@me.com:
Hello,
i've set
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 20e424b3acdb0fea04e54720da33e3e5f6031816 (commit)
via
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 17bfe720a97c51ad1e6cc1268c5ef6e1b57a71e2 (commit)
via
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 64ca9549f1c8d0a357c99bcb3867298f52abc25c (commit)
via
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 303b405c16253eb1de9019e0a2556b20d0cf (commit)
via
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 20d0b37f4a0d8c08c4bf31440d8e1bc14cdd86b2 (commit)
via
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 05529c7109de9b0849a5304e63586bf9989e5fcc (commit)
via
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 e674af906ac5b18883c1a180434286b1e519de4d (commit)
via
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 05e1b3c17d45320410ef8c7e080a33766ca63c2a (commit)
via
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 6e567cabea8df6f8fc8c401f4b9bfe2997c4399e (commit)
via
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 b887bca6ee3651857be663fe1f2e2f2c1ed1ac1e (commit)
via
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 9d4394148a5180c46aee249564de44609fbe2594 (commit)
via
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 990c440ddd599d0bf4cad2cb7ac1688a42dca6d9 (commit)
via
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 57072c12d2e9302cefa66c96e55a595de085a161 (commit)
via
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 b74c35f57ef686c424d6dfbbc40c60cb05e6245b (commit)
via
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 8e2e36507dd324a252c27f77825be5dda2bbc528 (commit)
via
49 matches
Mail list logo
