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 it could even fail if you would provide the correct libraries the symbol is in using CMAKE_REQUIRED_LIBRARIES. So for me it looks like it could have the optimization problem, but that wouldn't be a problem here as the symbol itself is not what we are interested in at that point. But it's usage of CMAKE_REQUIRED_LIBRARIES is completely wrong in my eyes as it could make the test actually fail when it should be successful. It shouldn't use any libraries at all IMHO. And even then it could go wrong when you reintroduce a symbol from the standard libraries, which could cause an error in the linker because of duplicate symbols. Or one would have to drop the newly introduced symbol in this file at all, using _only_ the symbol from the provided libraries. And then we would have the optimization problem, but if that is solved the whole thing can be made reliable at all. 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. This one needs rework, too, but that should go into a separate topic. Opinions? Eike -- 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