Re: [cmake-developers] Problems with icons for Windows Store 10.0

Hi Roman, Glad to hear that it works. We discussed this when I implemented the feature, the only reason the functionality has been implemented is to supplement the intermediate projects that CMake produces that cannot easily be adapted for the requirements of a Windows Store application. For

Re: [cmake-developers] Patch: Don't emit warning when config file not found

On 10/05/2016 05:35 PM, Christoph Grüninger wrote: > Vc provides a ConfigVc.cmake. > > 1. When I use "find_package(Vc)", many users get warnings that neither > FindVc.cmake nor VcConfig.cmake is found. You can use find_package(Vc CONFIG) to drop the FindVc part of the message. > 2. When I

Re: [cmake-developers] Generator options per-directory v. global

On 10/05/2016 06:38 PM, Stephen Kelly wrote: > The suggestion to use the first cmMakefile for these kinds of definitions is > a good one > > 1) It can be documented that the variable can only be set in the top level > 2) It is what people already do probably > 3) It is more convenient than the

Re: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

On Wed, Oct 5, 2016 at 12:54 PM, Nils Gladitz wrote: > On 04.10.2016 11:20, Tobias Hunger wrote: >> >> On Mo, 2016-10-03 at 14:25 -0400, Brad King wrote: The list we need would thus be built up to contain all COMMAND arguments to add_test that are also build

Re: [cmake-developers] FastBuild Generator

Hi, I rebased the Fastbuild generator on the latest master, and pushed my work to fastbuild-master. There are still some test fail, a few are due to an arror in manifest management, where multiple binarie's build try to write to the same manifest file at the same time (e.g. ObjectLibrary). Some

Re: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

On 10/06/2016 01:45 PM, Stephen Kelly wrote: > I have encountered the implementation of CMP0065. As far as I can see, this > is the only use of CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS, and it is not > used for shared libraries, but for executables. Correct. It was about exporting symbols from

Re: [cmake-developers] FastBuild Generator

>* Please use Utilities/Scripts/clang-format.bash for > code style. This is easy to apply automatically later > so don't worry about it too much. I'll get on this soon, I like to have proper style. > * For final integration I'd like the commits to be squashed > and arranged in an organized

[cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

Hi, I have encountered the implementation of CMP0065. As far as I can see, this is the only use of CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS, and it is not used for shared libraries, but for executables. Finding uses of variables like that is hard because they could be composed like "CMAKE_"

Re: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

On 10/06/2016 03:46 PM, Stephen Kelly wrote: > Do you know what CMAKE_EXE_EXPORTS_${lang}_FLAG is? It is added to the > linkFlags already for executables with exports. Ah, that does appear to be the same thing. > Is CMP0065 adding redundant flags? The policy only affects executables without

Re: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

On 10/06/2016 02:06 PM, Stephen Kelly wrote: >> One could rename the variable in our own platform files >> but would have to also honor the old name just in case. > > That wouldn't be a rename. Sure it would. All the places that set the variable would have a new more understandable name. We

Re: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

Brad King wrote: out of place in cmLocalGenerator. If it were returned from cli.GetItems, >>> >>> Yes, it could be moved. >> >> Ok. I might look into that. > > It looks like OutputLinkLibraries currently puts the flag in the > linkLibs (which goes to the placeholder) but it > would

Re: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

Brad King wrote: > The variable name refers to flags needed when linking an executable *to* > shared libraries. It is a terrible name that has been around since the > earliest days. One could rename the variable in our own platform files > but would have to also honor the old name just in case.

Re: [cmake-developers] Generator options per-directory v. global

Brad King wrote: > On 10/05/2016 06:38 PM, Stephen Kelly wrote: >> The suggestion to use the first cmMakefile for these kinds of definitions >> is a good one >> >> 1) It can be documented that the variable can only be set in the top >> level 2) It is what people already do probably >> 3) It is

Re: [cmake-developers] FastBuild Generator

On 10/06/2016 08:32 AM, Charles Huet wrote: > Do you think it is time to start the review, or should it wait > until I have 100% of the tests passing ? Thanks for the update. Generally my reviews for new features mostly look at documentation, tests, style, etc. rather than at implementation