Re: [cmake-developers] Deterministic identifiers in CPack WiX generator
On 10/10/2013 04:47 PM, Nils Gladitz wrote: Thanks for the feedback! I'll try to fix the commit message. As far as I can tell there shouldn't be any lines longer than 79 characters. I used the cmake developer script to set up my repository which seems to have set up a hook script which checks this on commit as well. I even had to shorten some unrelated code to get it to pass the hook. I've set up my editor to show a border at 79 characters as well and can't see any line reaching over it. Is there something I'm overlooking? No, oops, I saw one of the removed lines as over-length. Thanks, -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] C++11 and target_compiler_feature proposal
On 10/10/2013 08:07 PM, Stephen Kelly wrote: So, I think this is a two dimensional calculation. There is a standard axis and a extension axis for the compiler flag, for GCC and clang at least. Yes. if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7) set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11) endif() Will this work for XL too? I wonder if we should always use the extension flag, unless otherwise specified with set(CMAKE_STRICT_CXX_STANDARD ON)? Because gnu++98 is the GCC default, someone could be using 'gnu template instantiation' in existing code, and then uses CMake to specify the need for variadic_templates, so we add -std=c++11 and boom - no more gnu extensions. As you point out the user would have to have modified the project anyway so at that point they can specify explicitly the default extensions they were using before. -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] C++11 and target_compiler_feature proposal
On 10/11/2013 02:16 AM, Rolf Eike Beer wrote: Brad, this is one of your dashboard machines. I currently can't find the mails where we discussed that. Can you please give Steven some information about this? Sorry, I have no idea to what dashboard machine, emails, feature, compiler, or problem you're referring. Can you be more specific please? The only mention of simulated compiler id recently has been the new support for Clang on windows simulating MSVC. -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] CMake unicode support
On 10/11/2013 12:05 AM, clin...@elemtech.com wrote: I've started some work towards supporting Unicode in CMake so I could get better support for building/testing our internationalized applications. https://github.com/clintonstimpson/CMake/commit/f08ca2ff65f434b2bc404000765a836880f78f0e Wow, thanks for working on this. There are plenty of changes in KWSys so the patch probably needs to be split up. Let's start with the KWSys pieces because that will try out use of the APIs everywhere quickly and before merging. Thanks, -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] Converting CMake documentation to reStructuredText and Sphinx
2013/10/11 Brad King brad.k...@kitware.com: On 10/11/2013 01:09 AM, Daniel Pfeifer wrote: Will it still be able to generate DocBook, so companies can include the documentation in their handbook? It can generate whatever Sphinx can generate. IIRC Sphinx does not currently support DocBook output but I see no reason it couldn't be taught to do so. That would be re-usable for many other packages that use Sphinx too. Comparing the expressiveness, extensability, and supported backends, can you explain why you would prefer rST over AsciiDoc? Somewhere I read the analogy markdown == child, docbook == adult w/ garb, asciidoc == adult w/ jeans t-shirt and I think that nails it pretty well. I thinks it was somewhere on http://asciidoctor.org/ cheers, Daniel -- 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] target sources property
Brad King wrote: On 10/10/2013 08:55 PM, Stephen Kelly wrote: Brad King brad.king@... writes: I just checked the VS 6, 9 and 11 IDEs and it is possible to mark a source file as excluded from certain configurations. Those versions represent all the VS generators. If listing all sources and marking each one excluded in specific configurations is sufficient to implement this feature then it should work for VS. Ok, I'll take your word for it :). I don't know enough about the VS generators to implement it for them. Can you compute the set of sources and objects for all configurations before generating any config, and for those that are the same across all configs do not do any special markings and put it in Xcode too? Then things would work except in the true per-config source file case. Yes, I think that's possible. 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] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/10/2013 08:07 PM, Stephen Kelly wrote: So, I think this is a two dimensional calculation. There is a standard axis and a extension axis for the compiler flag, for GCC and clang at least. Yes. if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7) set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11) endif() Will this work for XL too? I assume so. The only flag I'm aware of for XL is -qlanglvl=extended0x, and that is equivalent to -std=c++11 afaik. What are you referring to specifically? I wonder if we should always use the extension flag, unless otherwise specified with set(CMAKE_STRICT_CXX_STANDARD ON)? Because gnu++98 is the GCC default, someone could be using 'gnu template instantiation' in existing code, and then uses CMake to specify the need for variadic_templates, so we add -std=c++11 and boom - no more gnu extensions. As you point out the user would have to have modified the project anyway so at that point they can specify explicitly the default extensions they were using before. Hmm, this might be a sticking point. I'm in favor of sticking close to the defaults of the compiler. The user shouldn't have to tell CMake to use the extension if that is the default for the compiler anyway, just as a penalty for telling CMake about requiring variadic templates. 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 unicode support
Wow! Impressive... Good luck getting this into CMake; I'd love to see UNICODE support through and through. :-) David C. -- 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] Converting CMake documentation to reStructuredText and Sphinx
On 10/11/2013 10:43 AM, Daniel Pfeifer wrote: Comparing the expressiveness, extensability, and supported backends, can you explain why you would prefer rST over AsciiDoc? There is a good comparison chart here: http://en.wikipedia.org/wiki/Lightweight_markup_language#Comparison_of_language_features I don't want to get into an extended debate about the choice. They all have similar expressive power. I actually started with AsciiDoc originally and moved to reST later due to reasons that include: - License of supporting tools - Sphinx provides mature support for x-refs across multiple documents, indexing, searching, and extensions for things like scanning markup out of .cmake module sources directly - Personal preference for markup syntax I understand that you're frustrated by DocBook support being dropped, and that AsciiDoc supports DocBook, but trade-offs have to be made. It is not impossible to add DocBook support to Sphinx. -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] C++11 and target_compiler_feature proposal
On 10/11/2013 10:56 AM, Stephen Kelly wrote: I assume so. The only flag I'm aware of for XL is -qlanglvl=extended0x, and that is equivalent to -std=c++11 afaik. What are you referring to specifically? I was just touching back on the issue you originally raised about -qlanglvl=extended0x. I'm in favor of sticking close to the defaults of the compiler. The user shouldn't have to tell CMake to use the extension if that is the default for the compiler anyway, just as a penalty for telling CMake about requiring variadic templates. If it is a cross-platform project then it should not depend on a non-standard language feature without saying so. Once a project starts using the target_compiler_feature command then it should be aware of the implications. -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] [CMake 0014479]: XCODE_DEPEND_HELPER.make doesn't work with iOS applications
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14479 == Reported By:Michael Priestman Assigned To: == Project:CMake Issue ID: 14479 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2013-10-11 11:28 EDT Last Modified: 2013-10-11 11:28 EDT == Summary:XCODE_DEPEND_HELPER.make doesn't work with iOS applications Description: When working with static libraries in Xcode, there is a post-build step added by CMake to clean targets when a static lib is built. This is to work-around known limitations in Xcode. The file that does the real work is XCODE_DEPEND_HELPER.make, and it includes lines of the format: /bin/rm -f /path-to-outdir/bin/Debug/test.app/Contents/MacOS/test This works fine for Mac OS apps, but doesn't work correctly for iOS apps. In that case, the actual binary file is not inside a Contents/MacOS folder, but instead just directly under the app directory, so the correct command should be: /bin/rm -f /path-to-outdir/bin/Debug/test.app/test Is there some setting that the iOS.cmake toolchain could set that would alter what is generated in this file? Or would CMake need to be extended to allow customisation of this file? Steps to Reproduce: Create a CMake project that uses the ios-cmake toolchain (https://code.google.com/p/ios-cmake/) that contains a static lib and an iOS app that links against the static lib. Build the app. Then update the code in the library. When you build the app again, it won't relink the new library. Additional Information: Should this defect actually be raised against the ios-cmake toolchain project instead? == Issue History Date ModifiedUsername FieldChange == 2013-10-11 11:28 Michael PriestmanNew Issue == -- 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] Converting CMake documentation to reStructuredText and Sphinx
On Thursday 10 October 2013, Brad King wrote: ... There are plenty of Wiki sites that can stage the documentation until the new system is ready. I don't want to add --help-concepts just to drop it again one release later or have to support it forever when the new system has no explicit notion of a concept. The topic breaks some of the existing --help-* commands like --help-full, Do you mean there won't be an all-in-one page anymore ? I find that one very useful (and use it also to add the documentation for previous cmake releases in the cmake wiki ... still have to do this for 2.8.12). 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] CPack: 7-zip generator
On Thursday 10 October 2013, Pau Garcia i Quiles wrote: Hello, A few years ago, Ralf Habacker proposed and implemented a 7-zip generator for CPack: http://marc.info/?l=cmakem=124031321521852w=2 Despite positive review from Alexander Neundorf, it seems it was not included. Was there any reason for that? The thread looks somewhat unfinished, and Ralf simply didn't seem to reply anymore, it would have needed just some more pushing to get it in. In a project I'm working on currently, 7-zip vs ZIP makes a 3.5 to 1 difference in compressed size. 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] CPack: 7-zip generator
On Fri, Oct 11, 2013 at 5:40 PM, Alexander Neundorf neund...@kde.orgwrote: The thread looks somewhat unfinished, and Ralf simply didn't seem to reply anymore, it would have needed just some more pushing to get it in. What kind of pushing? Code polishing? Documentation? Tests? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] Converting CMake documentation to reStructuredText and Sphinx
On 10/11/2013 11:34 AM, Alexander Neundorf wrote: On Thursday 10 October 2013, Brad King wrote: The topic breaks some of the existing --help-* commands like --help-full, Do you mean there won't be an all-in-one page anymore ? There can be with a little more work beyond the current topic: * The cmRST processor is capable of starting with Help/index.rst and printing out all manuals at once. This will be useful only for human consumption because the output format is only meant to be human-readable text and does not conform to any markup. * Sphinx supports a singlehtml builder that can generate all the manual pages in one giant html file. I find that one very useful (and use it also to add the documentation for previous cmake releases in the cmake wiki ... still have to do this for 2.8.12). Huh? Why/where are you doing this? We already publish all version-specific documentation going back pretty far: http://www.cmake.org/cmake/help/documentation.html CMake: 2.8.11, 2.8.10, 2.8.9, 2.8.8, 2.8.7, 2.8.6, 2.8.5, 2.8.4, 2.8.3, 2.8.2, 2.8.1, 2.8.0, 2.6.x. CTest: 2.8.11, 2.8.10, 2.8.9, 2.8.8, 2.8.7, 2.8.6, 2.8.5, 2.8.4, 2.8.3, 2.8.2, 2.8.1, 2.8.0, 2.6.x. CPack: 2.8.11, 2.8.10, 2.8.9, 2.8.8, 2.8.7, 2.8.6, 2.8.5, 2.8.4, 2.8.3, 2.8.2, 2.8.1, 2.8.0, 2.6.x. http://www.cmake.org/cmake/help/v2.8.11/cmake.html http://www.cmake.org/cmake/help/v2.8.10/cmake.html http://www.cmake.org/cmake/help/v2.8.9/cmake.html http://www.cmake.org/cmake/help/v2.8.8/cmake.html ... -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] CPack: 7-zip generator
On Friday 11 October 2013, you wrote: On Fri, Oct 11, 2013 at 5:40 PM, Alexander Neundorf neund...@kde.orgwrote: The thread looks somewhat unfinished, and Ralf simply didn't seem to reply anymore, it would have needed just some more pushing to get it in. What kind of pushing? Code polishing? Documentation? Tests? Well, there was no acxtivity from Ralf anymore, and Eric is mostly maintaining cpack. Maybe you can push the code in a branch on cmake stage and try to get it accepted into master ? 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] C++11 and target_compiler_feature proposal
Am Freitag, 11. Oktober 2013, 09:19:46 schrieb Brad King: On 10/11/2013 02:16 AM, Rolf Eike Beer wrote: Brad, this is one of your dashboard machines. I currently can't find the mails where we discussed that. Can you please give Steven some information about this? Sorry, I have no idea to what dashboard machine, emails, feature, compiler, or problem you're referring. Can you be more specific please? The only mention of simulated compiler id recently has been the new support for Clang on windows simulating MSVC. There is one dashboard machine that uses a combined gcc+clang compiler. I remember having many problems when the tests error'ed out when the tests suddenly showed support for features not expected in some compiler version. If nothing comes right to your mind I'll dig further. 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] C++11 and target_compiler_feature proposal
On 10/11/2013 01:22 PM, Rolf Eike Beer wrote: There is one dashboard machine that uses a combined gcc+clang compiler. I remember having many problems when the tests error'ed out when the tests suddenly showed support for features not expected in some compiler version. If nothing comes right to your mind I'll dig further. No, sorry. What does combined gcc+clang mean? -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] target-LOCATION-policy topic
Steve,
Please extend the CMP0026 message to suggest file(GENERATE)
as a way of putting the target location in a generated file.
Some projects not supporting multi-config generators may
use LOCATION with configure_file.
Also, this policy means it will not be possible for a project
to support both the next release of CMake and CMake 2.8.4
unless it sets the policy to OLD, and 2.8.4 is not too old.
Generally I prefer to recommend against ever setting a policy
to OLD instead of fixing the code except in an existing project
release maintenance branch to quiet the warning.
Can the policy NEW behavior instead be to return the LOCATION
as a $TARGET_FILE:... generator expression? That would
allow projects to do
if(POLICY CMP0026)
cmake_policy(SET CMP0026 NEW)
endif()
get_property(loc TARGET myexe PROPERTY LOCATION)
add_custom_command(... ${loc} ...)
and work with both CMake 2.8.4 and with whatever release
includes the policy.
Thanks,
-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] Roadmap to CMake 3.0
Hi Folks, I think the time has come for a major version number bump to go with some major updates. I propose to skip preparing 2.8.13 in 'master' and go straight to 3.0.0. If necessary it would still be possible to support 2.8.12.1+ or 2.8.13+ maintenance releases by basing topics on older versions instead of master. The reasons we've been on 2.8.x for so long are: * 2.9.date was taken by CVS development versions when the 2.8.x series started just before conversion to Git. * 2.10 cannot be used because CMAKE_VERSION and if(. VERSION_LESS .) did not exist prior to CMake 2.6.3 so old code does floating-point comparisons of version numbers like 2.4, and 2.10 will look like 2.1 to such code. This will not be a problem for 3.x versions. * 3.x has been reserved for the future time when we have some major changes underway. This time has come. Potential changes motivating a major version number bump include: * New documentation system using reStructuredText and Sphinx. This will not be 100% workflow-compatible with the old documentation system as discussed in the relevant thread. * Policy CMP0026 changes behavior of the commonly-used LOCATION target property in favor of generator expressions. This is needed to move more logic to generate-time where it belongs. Steve can explain in more detail if anyone wants. A draft of this is already in 'next'. * New quoting syntax: Lua-style long-brackets. Quoting opens with [ followed by zero or more = followed by [ and closes with ] followed by the same number of = followed by ]. No evaluation is performed on the content. It is very nice for inline literal content. This is an incompatible change because unquoted arguments starting in [[, [=[, etc. will now be treated as opening long brackets (expecting a matching close bracket) instead of unquoted arguments. CMake 2.8.12 added a warning for this case. This happens at the parsing stage so we cannot use a policy for it. Fortunately this should be a rare occurrence in practice, but still should come with a major version number bump. * The cmake --build tool should share stdout and stderr with the caller instead of separately buffering/merging them. This will be an incompatible change possibly affecting user scripts in ways that should only come with a major version bump and release notes. * New policies to disable old commands that require significant amounts of C++ code to be kept around just to support them. These include (but may not be limited to): - exec_program: replaced by execute_process - export_library_dependencies: replaced by export()/install(EXPORT) - load_command: replaced by macros and functions; does not work when the toolchain does not match the CMake binary anyway - output_required_files: obscure * Drop the cmake -i wizard mode. This has long been replaced by ccmake, cmake-gui, or just cmake with -D options. * Drop implementation of compatibility modes with CMake versions prior to 2.4.0 which is now over 7 years old. Comments? -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] target-LOCATION-policy topic
Brad King wrote:
Steve,
Please extend the CMP0026 message to suggest file(GENERATE)
as a way of putting the target location in a generated file.
Some projects not supporting multi-config generators may
use LOCATION with configure_file.
Done.
Can the policy NEW behavior instead be to return the LOCATION
as a $TARGET_FILE:... generator expression? That would
allow projects to do
if(POLICY CMP0026)
cmake_policy(SET CMP0026 NEW)
endif()
get_property(loc TARGET myexe PROPERTY LOCATION)
add_custom_command(... ${loc} ...)
and work with both CMake 2.8.4 and with whatever release
includes the policy.
I don't know. That seems like a lot of magic and bound to break existing
code.
get_property(loc TARGET myexe PROPERTY LOCATION)
file(WRITE some_script.bat ./${loc})
KDE4 does this:
get_target_property(_executable ${_target_NAME} LOCATION )
set_target_properties(${_target_NAME} PROPERTIES WRAPPER_SCRIPT
${_executable})
and the WRAPPER_SCRIPT is used elsewhere.
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] target-LOCATION-policy topic
On 10/11/2013 03:21 PM, Stephen Kelly wrote:
Brad King wrote:
Can the policy NEW behavior instead be to return the LOCATION
as a $TARGET_FILE:... generator expression?
I don't know. That seems like a lot of magic and bound to break existing
code.
get_property(loc TARGET myexe PROPERTY LOCATION)
file(WRITE some_script.bat ./${loc})
Yes, but that code will get the policy warning until someone
reads the policy documentation, sets it to NEW, and then
takes responsibility for using the new behavior properly.
OTOH, there is too much danger of setting it in one place
and having that silence the warning in other places instead
of generating an error on them.
Instead projects can do
if(NOT CMAKE_VERSION VERSION_LESS 2.8.4)
# use $TARGET_FILE:...
else()
# use LOCATION property
endif()
to support all versions regardless of the policy setting.
It is more verbose but more explicit, and projects can
potentially switch to this approach right now even before
the policy is introduced.
-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] Roadmap to CMake 3.0
Brad King wrote: * New policies to disable old commands that require significant amounts of C++ code to be kept around just to support them. These include (but may not be limited to): - exec_program: replaced by execute_process - export_library_dependencies: replaced by export()/install(EXPORT) - load_command: replaced by macros and functions; does not work when the toolchain does not match the CMake binary anyway - output_required_files: obscure Can we do something against link_directories, please? This is a common pitfall for everyone coming from plain Makefiles and probably other people, too. Just out of curiosity: is the Lua integration affecting the set of supported compilers? 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] Lua-style long brackets (was: Roadmap to CMake 3.0)
On 10/11/2013 03:34 PM, Rolf Eike Beer wrote:
Just out of curiosity: is the Lua integration affecting the set
of supported compilers?
There is no integration of Lua's source code in my outline. It is
only a change to the CMake language lexer/parser to handle Lua-style
long-bracket syntax. For example:
file(WRITE myfile.txt [[
This is the first line!
Arbitrary content without:
- ${variable} evaluation
- \-escapes
- -quoting
]])
instead of
file(WRITE myfile.txt This is the first line!
Arbitrary content without:
- \${variable} evaluation
- \\-escapes
- \-quoting
)
It will also support long-bracket comments, e.g.
#[[
This is a multi-line comment that can contain arbitrary text except
for the close bracket of equal length. It is great for long
explanations, copyright notices, and commenting out large blocks
of code. The closing bracket does not need to start in #, but if
it does then a one-character change to the opening bracket to be
##[[ would enable the entire block and the ending line
would be a normal one-line comment.
#]]
-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
