On 1/7/2012 6:12 AM, Rolf Eike Beer wrote:
This has changed. It fails now for vs11-x64 on amber10 and for Linux64-
bullseye-cov on hythloth. amber10 seems to have an unrelated, general problem.
What's wrong with the bullseye I have no idea, but this goes wrong for the C++
test and some others,
On 1/9/2012 9:19 AM, Rolf Eike Beer wrote:
What about just putting using std; before the main? Does that help?
I assume you mean
using namespace std;
Yes, it works. That will also take care of the normal cerrno case.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware
On 1/5/2012 8:25 AM, Brad King wrote:
So I will go and fix some small typos I've found in the existing tests,
repush and merge to next, so we see if Check*SymbolExists will work.
Sounds good.
The new CheckSymbolExists test works everywhere!
Brad King wrote:
On 1/5/2012 8:25 AM, Brad King wrote:
So I will go and fix some small typos I've found in the existing
tests,
repush and merge to next, so we see if Check*SymbolExists will work.
Sounds good.
However the CheckCXXSymbolExist test fails:
On 1/6/2012 1:55 PM, Rolf Eike Beer wrote:
The difference is that my test only does configuration and does not build an
executable, so the --build-and-test stuff will not work.
Lots of tests are like that. They just create a tiny dummy executable
to build and link. That's why I pointed at
Brad King wrote:
Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it
has the same problem.
I have looked into this and I don't think it has. The subject of this
thing is to provoke a compile error if the prototype doesn't match. And it
even introduced the symbol _itself_, so
On 1/5/2012 4:47 AM, Rolf Eike Beer wrote:
Brad King wrote:
Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it
has the same problem.
I have looked into this and I don't think it has.
Okay. As you said the concerns with that one are another topic.
So I will go and fix
On Tue, Jan 3, 2012 at 2:17 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Pushed updated branch. Please review and merge to next if you like it.
Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it
has the same problem.
Will look at.
There are a few problems with the current
On 1/4/2012 9:50 AM, Rolf Eike Beer wrote:
Nice. Will clean this up. When I put this directly into the CMakeLists.txt
the other problems should vanish, no?
Yes, I think so. That is one reason I suggested the approach.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware
Am Mittwoch, 4. Januar 2012, 10:02:32 schrieb Brad King:
On 1/4/2012 9:50 AM, Rolf Eike Beer wrote:
Nice. Will clean this up. When I put this directly into the CMakeLists.txt
the other problems should vanish, no?
Yes, I think so. That is one reason I suggested the approach.
Ok, I've
On 1/2/2012 5:24 PM, Rolf Eike Beer wrote:
It looks like gcc simply optimizes out any reference to the tested symbol.
Given the fact that we don't really ever use that symbol anywhere it is even
correct to do so. Just that this is not what we want.
Yuck. Clearly a less-optimizable approach is
On Tue, Jan 3, 2012 at 2:17 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Sorry, that was not intentional. I dropped the previous branch and created a
new one, based on current master. It has 2 commits: the first one introducing
the (hopefully) fixed CheckSymbolExists.cmake, the second one adding
In case anyone has a deja-vu: yes, it's true. This problem came up when I
tried to fix bug 11333. Once a fix for that was out a user found out that his
pthreads library was no longer detected. The root cause for this is that the
CheckSymbolExists and CheckCXXSymbolExists macros do not work if
13 matches
Mail list logo
