[cmake-developers] compile-defs-debugging and framework-interface-includes
Hi there, compile-defs-debugging is failing with some Visual Studio generators. I don't have those ides to figure out what is going wrong. My reading of the Preprocessor test indicates that if my new test fails, that one should too, so I don't understand where the problem is. The framework-interface-includes test is also failing on all macs, after I changed it to use a regex to match a framework. I don't have ready access to a mac for a few days to find out what is wrong there. Can I get some help with those issues? Thanks, Steve. -- 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] compile-defs-debugging and framework-interface-includes
- Original Message - Hi there, compile-defs-debugging is failing with some Visual Studio generators. I don't have those ides to figure out what is going wrong. My reading of the Preprocessor test indicates that if my new test fails, that one should too, so I don't understand where the problem is. The framework-interface-includes test is also failing on all macs, after I changed it to use a regex to match a framework. I don't have ready access to a mac for a few days to find out what is wrong there. Can I get some help with those issues? Thanks, Steve. I've pushed a fix for you on stage/framework-interface-includes. Clint -- 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] compile-defs-debugging and framework-interface-includes
clin...@elemtech.com wrote: The framework-interface-includes test is also failing on all macs, after I changed it to use a regex to match a framework. I don't have ready access to a mac for a few days to find out what is wrong there. I've pushed a fix for you on stage/framework-interface-includes. Awesome, thanks. I've squashed it into the original. Thanks, Steve. -- 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 dashboard test failures
Thanks, Rob. Looking forward to green rows from my machines again D From: Robert Maynard Sent: Monday, July 22, 2013 11:23 AM To: Brad King Cc: David Cole; CMake Developers; Stephen Kelly Yeap, I was the one that introduced this error. I have just pushed a new topic to next, that in testing on my windows machine fixed the problem. On Mon, Jul 22, 2013 at 9:27 AM, Brad King brad.k...@kitware.com wrote: On 07/21/2013 11:59 AM, David Cole wrote: Tests “ObjectLibrary” and “Qt4Automoc” are failing on my dlrsoftware dashboard machines, submitting ninja dashboards using the VS 2010 compiler. Likely culprits are commits from Rob and Stephen... (Could you guys please take a look?) Let me know if you need any additional information from the machines that run these. I can even give you remote access if you need to try something out on there yourself. Both test failures have messages like: ninja: warning: multiple rules generate A\CMakeFiles\A.dir\a1.c.obj. build will not be correct; continuing anyway so I suspect it may have to do with Robert's ninja_phony_targets topic. -Brad-- 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-developers] Fwd: [Bug 1203786] [NEW] Invalid handling of linker flags during build
Original Message Subject: [Bug 1203786] [NEW] Invalid handling of linker flags during build Date: Mon, 22 Jul 2013 15:31:47 - From: Rodney Dawes 1203...@bugs.launchpad.net Reply-To: Bug 1203786 1203...@bugs.launchpad.net To: cm...@packages.qa.debian.org Public bug reported: When building a project using cmake, which contains a shared library, and any code which uses that shared library, such as test programs, installed application, or plug-ins for other applications or libraries, cmake incorrectly applies all of the linker flags from the shared library, to all of the resulting objects which depend on it. This makes using certain linker features, such as version scripts, very problematic. This problem is then compounded when building with a builddir != srcdir setup, as the possible workaround of using a relative file name for --version-script and including an additional version script which exports all the symbols, cannot be used. The linker flags for a shared library should never be copied over to the other targets which depend upon that library. ** Affects: cmake (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1203786 Title: Invalid handling of linker flags during build Status in “cmake” package in Ubuntu: New Bug description: When building a project using cmake, which contains a shared library, and any code which uses that shared library, such as test programs, installed application, or plug-ins for other applications or libraries, cmake incorrectly applies all of the linker flags from the shared library, to all of the resulting objects which depend on it. This makes using certain linker features, such as version scripts, very problematic. This problem is then compounded when building with a builddir != srcdir setup, as the possible workaround of using a relative file name for --version-script and including an additional version script which exports all the symbols, cannot be used. The linker flags for a shared library should never be copied over to the other targets which depend upon that library. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1203786/+subscriptions -- 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 dashboard test failures
Yeap, I was the one that introduced this error. I have just pushed a new topic to next, that in testing on my windows machine fixed the problem. On Mon, Jul 22, 2013 at 9:27 AM, Brad King brad.k...@kitware.com wrote: On 07/21/2013 11:59 AM, David Cole wrote: Tests “ObjectLibrary” and “Qt4Automoc” are failing on my dlrsoftware dashboard machines, submitting ninja dashboards using the VS 2010 compiler. Likely culprits are commits from Rob and Stephen... (Could you guys please take a look?) Let me know if you need any additional information from the machines that run these. I can even give you remote access if you need to try something out on there yourself. Both test failures have messages like: ninja: warning: multiple rules generate A\CMakeFiles\A.dir\a1.c.obj. build will not be correct; continuing anyway so I suspect it may have to do with Robert's ninja_phony_targets topic. -Brad -- 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] Please review CXXFeatures.cmake
On Friday 19 July 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Monday 29 April 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. is this in master in the meantime ? I can't find it, or has it been renamed ? Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. The variable is case-sensitive, so it is CXXFeatures_FIND_COMPONENTS, not CXXFEATURES_FIND_COMPONENTS. I'm not sure I would have made this a find-module, instead of a simple module which can be included and then provides a function, but I think this doesn't matter much. And of course, before merging into cmake, the cmake_minimum_required() call can be removed. Alex -- 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] FindBacktrace.cmake
On Wednesday 03 July 2013, Vadim Zhukov wrote:
2013/7/3 Brad King brad.k...@kitware.com:
On 7/3/2013 11:09 AM, Vadim Zhukov wrote:
I'm an OpenBSD developer, working mostly on porting software. Most of
my work is related to CMake-based land, including modern KDE and some
other Qt4-based stuff.
Great, thanks for coming to us.
Here is a module I constructed a few months ago. It's helpful for
programs that want to use GNU-style backtrace(3) routine, which could
be found in different libraries and be declared in different headers
across OSes outta there.
Thanks for working on this. It looks similar to FindThreads in that
the results could be builtin to the system libraries or in one of
several other vendor-specific libraries. Don't model the module after
FindThreads though as that is one of the oldest modules and does not
fully use modern conventions.
The BACKTRACE_INCLUDE_DIR and BACKTRACE_LIBRARY variables should
not be documented as results that consuming projects should use
directly. They are inputs to the module that end users edit in
the cache. The results go in BACKTRACE_INCLUDE_DIRS and
BACKTRACE_LIBRARIES. Look at how FindProtobuf.cmake separates
the list of variables in its documentation, for example.
Thank you, that was exactly info I was looking for!
The line
set(BACKTRACE_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES})
looks a bit strange to me. The CMAKE_REQUIRED_LIBRARIES variable
is an input to the check_* APIs and should not be depended upon
or used by a find module. When calling check_symbol_exists you
should set CMAKE_REQUIRED_* to known values not depending on the
calling context. In the case that some non-standard/non-system
library is needed to provide the symbol it should be set by the
user through the BACKTRACE_LIBRARY code path.
Yes, I was not sure if this should be done this way either. Other variants
are:
1. find_library(c) - not as stupid as it looks from the first time,
because C++ compiler could be called with -nostdlib, for example (and
this was the reason for inclusion of CMAKE_REQUIRED_LIBRARIES
initially);
2. Just make sure BACKTRACE_LIBRARIES is empty: if the developer wants
to shoot himself in the foot with -nostdlib, then he's responsible for
the all consequences; and if he wants to avoid -lc, well, he'll
successfully avoid it.
I'd go with either way. For this try I choosed (2).
Otherwise, the module looks like a great start!
Thank you for review. I'm sending updated module now. Aside tweaks
based on your input, I realized that there should be a way for the
user to specify BACKTRACE_HEADER, too. I hope that I did not
overcomplicate things.
A few more style-comments:
please use empty else() and endif() clauses. Most of the cmake modules have
been converted to this style recently.
The variables should not use BACKTRACE as prefix, but Backtrace, so they
match the name of the find-module exactly.
Why do you make BACKTRACE_HEADER INTERNAL ? I think INTERNAL variables are
completely hidden, i.e. not accessible, e.g. in cmake-gui.
You use message() without the STATUS keyword. I think it should be used.
Can you switch to the new-style FPHSA() ?
This would be
find_package_handle_standard_args(Backtrace
REQUIRED_VARS ${_BACKTRACE_STD_ARGS} )
Thanks
Alex
--
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] FindBacktrace.cmake
On Tuesday 09 July 2013, Brad King wrote: On 07/08/2013 05:51 PM, Vadim Zhukov wrote: I'm not sure whether resetting CMAKE_REQUIRED_* is the desired behavior. The example in the CMakePushCheckState.cmake documentation tells the opposite, and I think that appending values have a point by adding some sort of a flexibility for writers of other CMake project files and other CMake modules. Also, I see the same logic (append instead of rewrite) is used in other CMake modules (in KDE at least, where CMakePushCheckState.cmake did came from). And if CMAKE_REQUIRED_* should be generally reset within module, then I propose adding a third macro in CMakePushCheckState.cmake, say, cmake_reset_check_state(), which will do this. I'm adding Alexander Neundorf to the thread to make things more clear, as he developed CMakePushCheckState.cmake module. Alexander, could you, please, explain the way CMakePushCheckState macros should be used? I would like Alex's opinion on this, but we must either use CMAKE_REQUIRED_* to report the results (as you did originally) or not use the caller's CMAKE_REQUIRED_* to perform the test. Otherwise the results will not be consistent. We have never (intentionally) defined CMAKE_REQUIRED_* as the input to a _find_ module before, only to _check_ macros. The check state stack module helps a project handle its own check accumulation Yes, that was the intention. Adding a cmake_reset_check_state() sounds good. and AFAIK is not meant as an API between a project and CMake find modules. It looks like a few find modules already use check macros and do not pay any attention to whether CMAKE_REQUIRED_* is defined. These may also need to be cleaned up based on the results of this discussion. I found it only in FindGIF.cmake right now. There the reset() could be used then. Alex -- 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-developers] Allowed chars in test names
Since d0170584c54b515b7eb2d044c3d48332523b3a37 there is a comment stating that spaces, quotes, or other characters special in CMake syntax are not allowed in a test name. This raised 2 topics: -first: the only check done in add_test() is that the name is not empty. If there are forbidden characters we must test for them, reject everything that is invalid, and have a check that verifies that this works. I've been fooled at least twice myself when adding a test with a space in the name and then wondering why it didn't work. -second: what does special mean? I fear that any test name would end up as some sort of target name in Makefile/project files somewhere, in which case we are limited to the valid subset of all supported generators. Which can be something like [a-zA-Z0-9_] with special rules like must not start/end with $something. And maybe even some case problems? So, who can shed some light on this? Brad? Eike signature.asc Description: This is a digitally signed message part. -- 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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. Has anyone anything else, otherwise I will o and put this into CMake next once I have the test. Do you have any response to the issue from Thiago here? http://thread.gmane.org/gmane.comp.kde.devel.core/80156/focus=80172 The header generated by your module would have to be installed, right? Otherwise it would make more sense to just use 'override' directly. The generated header is specific to whatever compiler was used when cmake generated it. Thanks, Steve. -- 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] Please review CXXFeatures.cmake
Stephen Kelly wrote: Rolf Eike Beer wrote: Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. Has anyone anything else, otherwise I will o and put this into CMake next once I have the test. Do you have any response to the issue from Thiago here? http://thread.gmane.org/gmane.comp.kde.devel.core/80156/focus=80172 The header generated by your module would have to be installed, right? Otherwise it would make more sense to just use 'override' directly. The generated header is specific to whatever compiler was used when cmake generated it. I don't generate a header. What I proposed there was to return a list of compat definitions. But those will for reasons said e.g. by Michael Pyne not include a definition for override. Currently there is no such list generated at all. What it indeed could include would be -D nullptr=0 and -D static_assert(x, y)= or the proper, compiler dependent form of those. Eike -- signature.asc Description: This is a digitally signed message part. -- 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
