[cmake-developers] Incorrect path handling in generation of export files
Hi, There is a bug in CMake's export file generator where it does not correctly escape Windows paths when generating export files . This was originally reported on the LLVM mailing list [1]. I'm using CMake 3.2.3. In a generated export file I see ``` # Create imported target LLVMDebugInfoPDB add_library(LLVMDebugInfoPDB STATIC IMPORTED) set_target_properties(LLVMDebugInfoPDB PROPERTIES INTERFACE_LINK_LIBRARIES "LLVMObject;LLVMSupport;C:\Program Files (x86)\Microsoft Visual Studio 14.0\DIA SDK\lib\diaguids.lib" ) ``` One of the libraries listed in the INTERFACE_LINK_LIBRARIES has invalid syntax because the slashes have not been escaped. I believe the correct solution would be to have CMake convert all paths to CMake style paths before writing them to export files. Brad King (CC'ed) had this comment ``` However, CMake should also be taught to escape the backslashes correctly when generating the export files. Take a look at Source/cmExportFileGenerator.cxx Source/cmExportBuildFileGenerator.cxx Source/cmExportInstallFileGenerator.cxx in the CMake source tree. There are several places that just generate double quotes around a raw value that should instead use EscapeForCMake. ``` [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/086958.html Thanks, Dan -- 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] Add command line options for deprecation message control
Hi Brad,
Apologies for taking a little while with this. I've addressed those
points and added all the tests I think are appropriate for this, however
when I run one of them it fails because stderr is not as expected, but
the actual and expected values are identical. Why would this happen?
Test I'm running:
/run_cmake_command(W_bad-arg1 ${CMAKE_COMMAND} -W)/
Output from running the test:
/ W_bad-arg1 - FAILED://
//
// stderr does not match that expected.//
//
// Command was://
//
// command> "/home/mike/Documents/cmake/src/cmake/bin/cmake" "-W"//
//
// Actual stdout://
//
// actual-out> //
//
// Expected stderr to match://
//
// expect-err> CMake Error: -W must be followed with
[no-][error=].//
// expect-err> CMake Error: Problem processing arguments. Aborting.//
//
// Actual stderr://
//
// actual-err> CMake Error: -W must be followed with
[no-][error=].//
// actual-err> CMake Error: Problem processing arguments. Aborting./
Cheers,
Michael
On 15/06/2015 15:06, Brad King wrote:
On 06/13/2015 01:41 PM, Michael Scott wrote:
I've implemented some changes to cmake.cxx and cmake.h, to implement
setting the CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED variables
via command line options, for the Mantis issue 0014669, in a generic GCC
style pattern. I've attached the proposed patch to this email, does this
look like a sensible implementation?
Thanks for working on this. Here are some comments:
* Please use 2 spaces and no tabs for indentation.
* Please extend Tests/RunCMake/CommandLine to cover this or find
another appropriate test to update. All options need coverage,
including the error cases.
* The cmHasLiteralPrefix helper function may be useful in place
of "x.find(...) == 0".
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] A policy for Policies
On Saturday, June 20, 2015 11:29:46 Stephen Kelly wrote: > Brad King wrote: > > > > I recommend the following guidelines: > > 1) Policies need to result in errors in a short timeframe. They are not > something to ignore for years, because allowing that makes them feature > toggles. Alex won't be happy with this one obviously, but that's what I > recommend. Just replace "Alex" with "Users who don't want to spend time babysitting their buildsystem, ". > 2) Policies need to result in unconditional warnings in a short timeframe. > Even -Wno-dev should have no effect on the warning when the warning is > unconditional. If third parties are using -Wno-dev to silence output they > need to know that will no longer work. It only works while there is an OLD > state for the policy. > > I don't think more conditions with deprecation states is a good idea. Policy > lifecycle should be simple to understand. It should be a loud notification > to people who see it that they have an action item on their hands. > > Here's my recommendation for a way forward: > > CMake 3.4: > > * Policies <= CMP0011 > -- emit unconditional warnings for each policy (no OLD anymore - 6 years > old) > > * Policies CMP0051 -> CMP0054 > -- emit unconditional warnings for each policy (no OLD anymore - 3 releases > old) > > * Policies CMP0026, CMP0024 > -- emit unconditional warning (CMP0026 warning will be in place for longer > as many are affected, so start unconditional warning now). These are high > priority because they make a better CMake implementation possible. > > CMake 3.5: > > * Policies CMP0001, CMP0003, CMP0004, CMP0006 -> CMP0010 > -- emit unconditional errors for each policy (the ancient ones except 'the > KDE4 policies') Just so it doesn't sound only stupid: when I was still maintaining the KDE4 buildsystem, I tried to avoid forcing users to have to update CMake (I always hate it if I try to do something on KDE, but instead of being able to start to do something, first I have to spend a day or two updating various stuff). Ok, I wanted to avoid that for the cmake part. So, let's say some version of KDE was released requiring CMake 2.4.5 (yeah, that old). As long as there was no strong reason to require a newer version of CMake, I kept it at 2.4.5. Which implied, that the source should still be compilable with 2.4.5. Which, (at least to be on the safe side), also means, if there is a policy which results in a warning e.g. in 2.6.0, developers should not fix that warning with 2.6.0, since this might mean it does not work anymore with 2.4.5. Once a newer version of cmake is required, those policy settings may be changed. But even doing this means that developers may have to relearn some of their cmake skills, which is a cost, and shouldn't be forced without good reason. Also, given the KDE4 source compatibility guarantees, kdebase 4.12 should still compile with kdelibs 4.3, and changing the cmake environments kde4libs is setting up influences this (and I had the impression that the uptake of more advanced cmake features in the wider KDE community was quite slow, e.g. learning about the subtleties of cmake policies). So to me this still sounds reasonable. ... > Of course all of this needs to be malleable. Let's see what the response is > to the warning behavior in 3.4 if you apply it. If there is a fixed date when the policy will result in an error, I'd consider it useful to have that date printed as part of the warning message. Alex -- 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] astyle cofiguration for CMake coding?
Thanks, I think this should be enough for me to configure the visual studio
plugin accordingly.
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Monday, June 22, 2015 3:43 PM
> To: Stuermer, Michael SP/HZA-ZSEP; cmake-developers@cmake.org
> Subject: Re: [cmake-developers] astyle cofiguration for CMake coding?
>
> On 06/22/2015 03:36 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
> > Directions where I can find a complete set of rules how the code
> > should be formatted would also suffice.
>
> We don't have it formally documented anywhere. Basics:
>
> * 79 columns or less (only one that is enforced with a test)
> * indent with 2 spaces, no tabs
> * opening '{' gets its own line and aligns with inner code
> * CamelCase names for class members
> * this->Member for references to class members
>
> Generally just try to match style of surrounding code.
>
> -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] astyle cofiguration for CMake coding?
On 06/22/2015 03:36 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
> Directions where I can find a complete set of rules how the
> code should be formatted would also suffice.
We don't have it formally documented anywhere. Basics:
* 79 columns or less (only one that is enforced with a test)
* indent with 2 spaces, no tabs
* opening '{' gets its own line and aligns with inner code
* CamelCase names for class members
* this->Member for references to class members
Generally just try to match style of surrounding code.
-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] Discussion needed: FindBISON: refine VERBOSE feature of BISON_TARGET
On 06/21/2015 09:06 AM, 정언 wrote: > internal macro defines a custom command that makes a copy of the > default named report file to the specified path. The custom > command is not invoked until any other command requires the , > for example, from its dependencies. This could be fixed by moving the copy logic to a second COMMAND argument to the add_custom_command for the actual bison invocation. > It is possible to specify a non-default report file path in command > line. The bison command line option `--report-file` is used to do > that. I think that can be added as a separate REPORT_FILE option that is considered separately from the VERBOSE option and uses --report-file. It could be an error if the discovered bison tool does not support the option. 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] Problems when creating config files and add_dependencies
On 06/20/2015 04:10 AM, Roman Wüger wrote: > but the problem with this command is, that for multi configuration > environments (e.g. Visual Studio), it requires $ in the > filename which then creates 4 header files. One for each configuration. Yes, because generator expressions can reference things that depend on the configuration. configure_file does not support them because its result does not depend on the configuration. I guess I didn't understand what you meant by "generator expressions can be used with configure_file to avoid such overhead". Returning to the original problem, the circular dependency may appear because using $ in a custom target results in an ordering dependency on the target named in the generator expression. To confirm this, try hard-coding the path by hand for one example. -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] astyle cofiguration for CMake coding?
Does anyone have a configuration for astyle which indents my code according to the CMake coding rules? Would make my life much easier right now. Directions where I can find a complete set of rules how the code should be formatted would also suffice. best regards Michael Stürmer -- 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
