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 exports, so it makes no
difference for anything that is getting CMAKE_EXE_EXPORTS_${lang}_FLAG.
However, the code path where the policy appears was already adding
redundant flags.
I think CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS values in platform
files can be copied over to CMAKE_EXE_EXPORTS_${lang}_FLAG where they
are not set already. Then the policy's NEW behavior can be changed
to doing nothing because executables with exports will already have
the flags needed. The only reason to keep the old settings of
CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS around is then to honor the
CMP0065 OLD behavior.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
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 more sensibly be located in the linkFlags (which goes to
> the placeholder). If we do clean this up it should
> be moved to . Therefore it should not go in GetItems,
> but instead in a separate helper that all generators can share.
Do you know what CMAKE_EXE_EXPORTS_${lang}_FLAG is? It is added to the
linkFlags already for executables with exports.
For Linux, it contains
"-Wl,--export-dynamic"
CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS contains
"-rdynamic"
for Linux-GNU.
According to
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
rdynamic means:
"Pass the flag -export-dynamic to the ELF linker, on targets that support
it."
Is CMP0065 adding redundant flags?
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
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 would just leave undocumented support for reading the old name if it is set and otherwise use the new name. Actually since this is an internal variable I'd be okay with renaming it without compatibility, so long as it is easy to add support for the old name back in if it becomes a problem in the future. Or, we could even rename support for the old name and then add a commit to remove the support. That would provide a commit that is easy to revert to restore support. >>> 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 more sensibly be located in the linkFlags (which goes to the placeholder). If we do clean this up it should be moved to . Therefore it should not go in GetItems, but instead in a separate helper that all generators can share. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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. That wouldn't be a rename. The infinite compatibility promises of CMake concern me. A policy could be added but those are also defined to never expire, so while they help users migrate, they don't help clean up code. End result: do nothing. >> Also, shouldn't that code be part of cmComputeLinkInformation? It seems >> out of place in cmLocalGenerator. If it were returned from cli.GetItems, >> then cmLocalVisualStudio7GeneratorInternals::OutputLibraries and >> cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it, >> which as far as I can tell they currently do not. Should/do those >> generators support ENABLE_EXPORTS? > > Yes, it could be moved. It hasn't really mattered because the variable > is not populated on the platforms supported by those other generators. Ok. I might look into that. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 executables so plugins can
see them. See the policy docs.
> Am I missing something or is that also used for shared libraries? Or should
> the variable be renamed? Or should CMP0065 be using some other appropriate
> variable?
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.
> Also, shouldn't that code be part of cmComputeLinkInformation? It seems out
> of place in cmLocalGenerator. If it were returned from cli.GetItems, then
> cmLocalVisualStudio7GeneratorInternals::OutputLibraries and
> cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it,
> which as far as I can tell they currently do not. Should/do those generators
> support ENABLE_EXPORTS?
Yes, it could be moved. It hasn't really mattered because the variable
is not populated on the platforms supported by those other generators.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[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_"
+ targetType
+ "_LINK_"
+ lang
+ "_FLAGS";
which is hard to find with grep.
Am I missing something or is that also used for shared libraries? Or should
the variable be renamed? Or should CMP0065 be using some other appropriate
variable?
Also, shouldn't that code be part of cmComputeLinkInformation? It seems out
of place in cmLocalGenerator. If it were returned from cli.GetItems, then
cmLocalVisualStudio7GeneratorInternals::OutputLibraries and
cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it,
which as far as I can tell they currently do not. Should/do those generators
support ENABLE_EXPORTS?
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
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 way. This is hard to do until > you have everything working though. Sure. For now there are the first few commits which I can't change much to keep proper attribuation, and a few commits on top which will be squashed together once the dev is complete (or maybe earlier if I feel like it). >* Please update the license notices to use the new style that > we switched to in `master`. Both C++ and .cmake notices > changed. Will do. Le jeu. 6 oct. 2016 à 17:32, Brad King a écrit : > 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 details (which can easily be fixed/changed > later). Therefore final review and integration should not start > until everything is working. > > However, I'm happy to take quick glances at progress once in > a while. Here are some comments from the current version: > > * 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. > > * For final integration I'd like the commits to be squashed > and arranged in an organized way. This is hard to do until > you have everything working though. > > * Please update the license notices to use the new style that > we switched to in `master`. Both C++ and .cmake notices > changed. > > Thanks, > -Brad > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 more convenient than the API for setting cache or global >> properties > > That makes sense, but the codelite feature is just following a > long-standing convention used for many settings. If you want to > make a sweeping effort to formalize this kind of scoping then that > is fine with me. Mostly I think it will be documenting that the > value of the variable at the end of the top-level CMakeLists.txt > file is the one that is used. In some cases that may involve > fixing generators to actually use that one. Ok. I started by adjusting the new CodeLite feature. I based it on an early commit so that it can be merged to the release branch. The sweep belongs in master for the following release I think. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 details (which can easily be fixed/changed later). Therefore final review and integration should not start until everything is working. However, I'm happy to take quick glances at progress once in a while. Here are some comments from the current version: * 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. * For final integration I'd like the commits to be squashed and arranged in an organized way. This is hard to do until you have everything working though. * Please update the license notices to use the new style that we switched to in `master`. Both C++ and .cmake notices changed. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 API for setting cache or global properties That makes sense, but the codelite feature is just following a long-standing convention used for many settings. If you want to make a sweeping effort to formalize this kind of scoping then that is fine with me. Mostly I think it will be documenting that the value of the variable at the end of the top-level CMakeLists.txt file is the one that is used. In some cases that may involve fixing generators to actually use that one. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 use "find_package(Vc QUIET)", Vc does not show up in the > feature summary. Try: find_package(Vc CONFIG QUIET) Then use the `INCLUDE_QUIET_PACKAGES` option to feature_summary(): https://cmake.org/cmake/help/v3.7/module/FeatureSummary.html -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 issues are clearly identified but not solved yet, such as RunCMake.BuildDepends which fails because non-source dependencies are not yet managed properly. Some of these are new since the rebase on 3.7/master, either new tests (e.g. android-related) or regressions, I will work at identiofying and correcting those. Do you think it is time to start the review, or should it wait until I have 100% of the tests passing ? Here is a full list of failing tests: 93% tests passed, 28 tests failed out of 406 The following tests FAILED: 46 - ObjectLibrary (Failed) 52 - LinkDirectory (Failed) 61 - Preprocess (Failed) 62 - ExportImport (Timeout) 66 - CompileDefinitions (Failed) 76 - CMakeBuildTest (Failed) 79 - Module.ExternalData (Failed) 108 - CustomCommand (Failed) 109 - CustomCommandByproducts (Failed) 113 - BuildDepends (Failed) 114 - SimpleInstall (Failed) 115 - SimpleInstall-Stage2 (Failed) 131 - ExternalProject (Failed) 135 - ExternalProjectUpdateSetup (Failed) 136 - ExternalProjectUpdate (Failed) 153 - Plugin (Timeout) 225 - IncludeDirectories (Failed) 226 - InterfaceLinkLibraries (Failed) 276 - RunCMake.CMP0060 (Failed) 278 - RunCMake.CMP0065 (Timeout) 281 - RunCMake.AndroidTestUtilities (Failed) 282 - RunCMake.BuildDepends (Failed) 284 - RunCMake.Configure (Failed) 345 - RunCMake.try_compile (Failed) 372 - RunCMake.CrosscompilingEmulator (Failed) 374 - RunCMake.AutoExportDll (Failed) 389 - CMake.ModuleNotices (Failed) 406 - CMake.CheckSourceTree (Failed) Errors while running CTest Thanks. Le ven. 23 sept. 2016 à 17:21, Charles Huet a écrit : > Sorry I pushed on fastbuild-rebase, as the rebase on master fails evento > self host. > > I did not expect this to be merged for 3.7, as I'm not sure I'll have time > to polish it enough for release. > > On Fri, Sep 23, 2016, 16:52 Brad King wrote: > > On 09/23/2016 10:30 AM, Charles Huet wrote: > > If you want to take a quick glance it should be close to what you want > > Did you push an update to the fastbuild-master branch? It looks the same. > > FYI, I'd like to wait until after the Oct 3 branch for the 3.7 release > before introducing changes toward a major new feature. Therefore I > likely won't have a chance to take a serious look at this until after > that. > > -Brad > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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 targets in CMake. >>> >>> The list would also need to include targets mentioned in generator >>> expressions such as `$`. This will almost certainly >>> be better done as a CMake feature implemented in C++. This was actually >>> an early design philosophy: do the hard stuff in C++ so that complex >>> logic is not needed in CMake-language code. >> >> Access to the list of defined tests would be nice to have in the >> server-mode, >> too:-) >> >> If some work is done in that direction, please keep server-mode in mind >> when >> designing the APIs. I would love to reuse them to expose that information >> to >> clients. > > > This might be rare but the tests that cmake knows about might differ from > the tests that ctest knows about given that tests can be dynamically defined > through TEST_INCLUDE_FILE[1]. > > I've never used it that way but I was considering e.g. querying test > binaries (produced at build time) for the tests they define and making those > available dynamically when ctest processes CTestTestfile.cmake. This is in > contrast to e.g. FindGTests.cmake's GTEST_ADD_TESTS() which tries to > accomplish the same thing at configuration time by parsing test sources > instead. +1. I wrote about that approach here: http://purplekarrot.net/blog/cmake-and-test-suites.html -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
