Re: [cmake-developers] Generator expressions for output directory/name (and install?)
Ok let's start with the simplest one, OUTPUT_NAME generator expressions
support, then we'll do the others.
Patch in attachment.
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Tuesday, June 16, 2015 10:21 AM
To: Robert Goulet
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Generator expressions for output directory/name
(and install?)
On 06/15/2015 03:03 PM, Robert Goulet wrote:
> Updated with improved tests and added docs.
Thanks. Here are more comments.
Please split the patch to do the OUTPUT_NAME/dir changes first.
Update the Tests/PerConfig test to cover these. Since the
RUNTIME_OUTPUT_DIRECTORY properties are learning this, please do it for
ARCHIVE_OUTPUT_DIRECTORY and LIBRARY_OUTPUT_DIRECTORY too for completeness.
Then do the install DESTINATION changes in a second patch.
That will simplify review.
In this hunk:
>cmInstallTargetGenerator(
> -cmTarget& t, const char* dest, bool implib,
> +cmMakefile* mf, cmTarget& t, const char* dest, bool implib,
The cmTarget has a GetMakefile() method so there should be no need to pass the
mf separately.
In this hunk:
> @@ -216,6 +216,7 @@ void
> cmScriptGenerator::GenerateScriptActionsPerConfig(std::ostream& os,
> i != this->ConfigurationTypes->end(); ++i)
>{
>const char* config = i->c_str();
> + this->ConfigurationName = config;
>if(this->GeneratesForConfig(config))
> {
> // Generate a per-configuration block.
This should not be needed if things are factored correctly.
Everything in that block already passes "config" through as a parameter.
Thanks,
-Brad
output-name-genex.patch
Description: output-name-genex.patch
--
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] Macro generation for relaxed constexpr
Jean-Michaël Celerier wrote:
>> I think there should be a test for the different allowed contexts of the
> ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
> you extend Tests/Module/WriteCompilerDetectionHeader with a test for that?
>
> For sure, I'll do this asap.
>
Great, 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] [PATCH] Macro generation for relaxed constexpr
Jean-Michaël Celerier wrote:
>> I think there should be a test for the different allowed contexts of the
> ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
> you extend Tests/Module/WriteCompilerDetectionHeader with a test for that?
>
> For sure, I'll do this asap.
>
>> constexpr foo = ...;
>
> If I read http://en.cppreference.com/w/cpp/language/constexpr
> correctly, there should be no differences in variable handling between
> C++11 and 14 for constexpr, the changes are only for function bodies.
Right.
Qt 5 provides a macro for this context which expands to either 'const' or
'constexpr' depending on whether cxx_constexpr is available, and another
macro which expands to either 'const' or 'constexpr' depending on whether
cxx_relaxed_constexpr is available.
Compare the assembly of the following when compiled with -std=c++98/11/14:
#if __has_feature(cxx_constexpr)
#define DECL_CONSTEXPR constexpr
#else
#define DECL_CONSTEXPR
#endif
#if __has_feature(cxx_relaxed_constexpr)
#define DECL_RELAXED_CONSTEXPR constexpr
#else
#define DECL_RELAXED_CONSTEXPR
#endif
DECL_CONSTEXPR int getNumRegular()
{
return 42;
}
DECL_RELAXED_CONSTEXPR int getNumRelaxed()
{
int result = 0;
for (int i = 0; i < 4; ++i)
result += 10;
return result + 2;
}
DECL_CONSTEXPR int betterIfConstexprParameter(int param)
{
return param / 2;
}
#if __has_feature(cxx_constexpr)
#define CXX11_CONSTEXPR_VARIABLE constexpr
#else
#define CXX11_CONSTEXPR_VARIABLE const
#endif
#if __has_feature(cxx_relaxed_constexpr)
#define CXX14_CONSTEXPR_VARIABLE constexpr
#else
#define CXX14_CONSTEXPR_VARIABLE const
#endif
int main()
{
CXX11_CONSTEXPR_VARIABLE int num1 = getNumRegular();
CXX11_CONSTEXPR_VARIABLE int result1 = betterIfConstexprParameter(num1);
CXX14_CONSTEXPR_VARIABLE int num2 = getNumRelaxed();
CXX14_CONSTEXPR_VARIABLE int result2 = betterIfConstexprParameter(num2);
return result1 - result2;
}
$ wc -l 98.s 11.s 14.s
126 98.s
90 11.s
31 14.s
Of course, such macros don't belong in the same patch as the one you
submitted and could be in a follow-up.
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] [PATCH] CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking
On 07/08/2015 03:40 PM, Konstantin Podsvirov wrote: > I found that CPack IFW generator does not work on the basis QtIFW 2.0 > and above for projects which include CPackIFW.cmake module... This > hotfix corrects this chip :-) Applied, thanks: CPackIFW: Load module to set CPACK_IFW_FRAMEWORK_VERSION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad5c76af > Will be asked to contribute, what would this change was brought in > release 3.3. Yes, this falls in the "bug in new feature" category of allowed updates to the release. I've queued it for merge to the 'release' branch once it tests cleanly. 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] Add command line options for deprecation message control
On 07/08/2015 04:01 PM, Michael Scott wrote: > Making dev influence deprecation variables is not a problem. To support > -Werror=dev we'll need a new variable I'm thinking though, something > like a boolean CMAKE_SUPPRESS_DEVELOPER_ERRORS? Yes, thanks. > What should be the expected behaviour when combining dev and deprecated > now, as they affect each other. If for example the user used the options > "-Wno-deprecated -Wdev" in a cmake invocation, the most logical to me > would be that this causes CMAKE_SUPPRESS_DEVELOPER_WARNINGS to be TRUE > and CMAKE_WARN_DEPRECATED to be FALSE, but implementing that might make > the code more complicated than I'd hoped. Yes, I think you'll need some kind of tracking for what settings were explicitly specified. Thanks, -Brad P.S. Your mailer is breaking the message threading. -- 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] Macro generation for relaxed constexpr
> I think there should be a test for the different allowed contexts of the
${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
you extend Tests/Module/WriteCompilerDetectionHeader with a test for that?
For sure, I'll do this asap.
> constexpr foo = ...;
If I read http://en.cppreference.com/w/cpp/language/constexpr
correctly, there should be no differences in variable handling between
C++11 and 14 for constexpr, the changes are only for function bodies.
Jean-Michaël
On Wed, Jul 8, 2015 at 9:49 PM, Stephen Kelly wrote:
> Stephen Kelly wrote:
>
>> * A method marked constexpr will fail to compile with a compiler which
>> does not support relaxed constexpr if the method uses language which
>> requires relaxed mode (such as a for loop), even if the method is
>> evaluated in a non- constant expression. I tested GCC and Clang.
>
> Are there any values of '...' where
>
> constexpr foo = ...;
>
> would compile or not depending only on whether using cxx11-constexpr or
> cxx14-constexpr?
>
> 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
--
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
Since AUTHOR_WARNING is a superset of DEPRECATION_WARNING I think -W[no-]dev can influence CMAKE_WARN_DEPRECATED. Please also add -W[no-]error=dev to turn AUTHOR_WARNING into an error and also make it influence CMAKE_ERROR_DEPRECATED. Then -Wdeprecated and friends can still be used to control the DEPRECATION messages separately. Making dev influence deprecation variables is not a problem. To support -Werror=dev we'll need a new variable I'm thinking though, something like a boolean CMAKE_SUPPRESS_DEVELOPER_ERRORS? What should be the expected behaviour when combining dev and deprecated now, as they affect each other. If for example the user used the options "-Wno-deprecated -Wdev" in a cmake invocation, the most logical to me would be that this causes CMAKE_SUPPRESS_DEVELOPER_WARNINGS to be TRUE and CMAKE_WARN_DEPRECATED to be FALSE, but implementing that might make the code more complicated than I'd hoped. Cheers, Michael -- 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] Macro generation for relaxed constexpr
Stephen Kelly wrote: > * A method marked constexpr will fail to compile with a compiler which > does not support relaxed constexpr if the method uses language which > requires relaxed mode (such as a for loop), even if the method is > evaluated in a non- constant expression. I tested GCC and Clang. Are there any values of '...' where constexpr foo = ...; would compile or not depending only on whether using cxx11-constexpr or cxx14-constexpr? 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
[cmake-developers] [PATCH] CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking
Hi, Brad! A very small patch single commit from multiple rows in a topic branch 'cpack-ifw-generator' on my server: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cpack-ifw-generator Here is the commit itself: CPackIFW: Variable CPACK_IFW_FRAMEWORK_VERSION cheking http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=2d8a3bd27b2f2be911a3c8c30dd667460281beaf I found that CPack IFW generator does not work on the basis QtIFW 2.0 and above for projects which include CPackIFW.cmake module... This hotfix corrects this chip :-) Will be asked to contribute, what would this change was brought in release 3.3. -- Regards, Konstantin Podsvirov -- 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] Macro generation for relaxed constexpr
Jean-Michaël Celerier wrote:
> Hello,
>
> At the ned of this mail is a patch that adds generation of a macro for
> the relaxed ("c++14") constexpr in WriteCompilerDetectionHeader.
Thanks for working on this.
I have some thoughts for archival purposes on the mailing list. These aren't
things you necessarily need to address:
* I think I've read about constexpr being made even more relaxed in a
future CXX standard. Would we then call it 'yet_more_relaxed_constexpr'?
Clang, whose names CMake follows, likely won't introduce a name for it
because it will likely start to rely on SD-6 macros instead of extending
__has_feature. SD-6 doesn't have that problem because it would just use a
new value for the __cpp_constexpr macro (which already has two possible
values 200704 and 201304).
* The 'relaxed' name is already what is currently used for this feature.
Future developments don't really matter.
* It's appropriate for this macro to expand to empty if
cxx_relaxed_constexpr is not available, because a function marked constexpr
which is only cxx11-constexpr but not cxx14-constexpr will fail to compile
anyway. Programmers are aware of ways to implement methods in a way that is
cxx11-constexpr, even if making it cxx14-constexpr would be more
easy/readable.
* A method marked constexpr will fail to compile with a compiler which does
not support relaxed constexpr if the method uses language which requires
relaxed mode (such as a for loop), even if the method is evaluated in a non-
constant expression. I tested GCC and Clang.
So assuming all that is correct, I think this patch is good.
I think there should be a test for the different allowed contexts of the
${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
you extend Tests/Module/WriteCompilerDetectionHeader with a test for 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
[cmake-developers] [PREVIEW] Meet CMake components-based cross-platform GUI installer
All kind time of day! This is not the official installer, but who might someday become. Straight to the point - here online installers Debian 8: http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run Windows 7: http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe If you have ispolzovali them before, you can just be updated from "cmake-maintenance". Version for 32 bit will update the other day. Installers based on QtIFW 2.0.1. QtDialog (cmake-gui) for Windows is built on the basis of Qt 5.5. If some kind person can collect under MacOS it will be possible to please and lovers of apples. Source code in branch 'master' now. I will be glad to hear from you. If you have questions, ask it. -- Regards, Konstantin Podsvirov -- 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] Adding Swift support to CMake
On 07/08/2015 03:19 PM, Stephen Kelly wrote: > Seen this way, it looks like 'Apple' is the future proof compiler id and > 'AppleClang' is the outlier (an alias could be introduced). It is "AppleClang" because it is Apple's distribution of Clang. The reason it cannot just be "Clang" (like we use for Debian's distribution of Clang, for example) is that the version scheme is different. Perhaps it could have been "Apple" but we needed to keep "Clang" in the name for compatibility with code that checks if the compiler id MATCHES "Clang". Also during Apple's transition from GNU to Clang compilers it could have been confusing. The compiler id for the old Apple distributions of the GNU compiler should probably be AppleGNU because the feature set for each version number differs a bit, but those compilers are going away so there is no point in changing that now. > So, I don't think the name 'Apple' is so strange anymore. Okay, I think we'll stick with "Apple" for Swift. 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] Adding Swift support to CMake
Brad King wrote: > On 07/08/2015 03:04 PM, Stephen Kelly wrote: >> I guess. I think part of the reason it seems wrong to me is that there is >> a platform id called 'APPLE' (different case) and a variable of that name >> >> There is also an existing GNU platorm/compiler id (same case). >> >> If the same name is to be used, is there any reason not to use the same >> case? > > All compiler id values use CamelCase or are acronyms. The variable > named "APPLE" is historical and meant to match the __APPLE__ > preprocessor macro. Compiler id values are different. > > What do you think of Ben's "AppleSwift" suggestion? It made me wonder what would AppleClang be called if it was introduced in the future. If the Swift compiler id is 'Apple', and the Clang CXX compiler id was 'Apple' then we would have, eg Apple-CXX.cmake Apple-Swift.cmake instead of AppleClang-CXX.cmake Apple-Swift.cmake or AppleClang-CXX.cmake AppleSwift-Swift.cmake Seen this way, it looks like 'Apple' is the future proof compiler id and 'AppleClang' is the outlier (an alias could be introduced). So, I don't think the name 'Apple' is so strange anymore. 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] Adding Swift support to CMake
On 07/08/2015 03:04 PM, Stephen Kelly wrote: > I guess. I think part of the reason it seems wrong to me is that there is a > platform id called 'APPLE' (different case) and a variable of that name > > There is also an existing GNU platorm/compiler id (same case). > > If the same name is to be used, is there any reason not to use the same > case? All compiler id values use CamelCase or are acronyms. The variable named "APPLE" is historical and meant to match the __APPLE__ preprocessor macro. Compiler id values are different. What do you think of Ben's "AppleSwift" suggestion? -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] Adding Swift support to CMake
Brad King wrote: >> This seems somehow wrong. Naming it based on some state 'right now' >> doesn't seem future proof. The 'MSVC' compiler id is not called >> 'Microsoft', the 'QCC' compiler id is not called 'QNX', 'XL' is not >> called 'IBM'. > > The PGI compiler id is "PGI". The PathScale compiler id is "PathScale". > The TI compiler id is "TI". The GNU compiler id is "GNU". The Cray > compiler id is "Cray". The Absoft compiler id is "Absoft". There is > plenty of precedent to use the vendor name. I guess. I think part of the reason it seems wrong to me is that there is a platform id called 'APPLE' (different case) and a variable of that name There is also an existing GNU platorm/compiler id (same case). If the same name is to be used, is there any reason not to use the same case? 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] Adding Swift support to CMake
On Wed, Jul 08, 2015 at 14:42:03 -0400, Brad King wrote: > On 07/08/2015 02:35 PM, Stephen Kelly wrote: > > "Since Apple is the only vendor implementing the language > > right now, the compiler id can be just `Apple`." > > Even if another vendor implements it the one we're identifying > will still be provided by "Apple". The above wording was poor. Or it could follow Clang and there's the FOSS swiftc and then there's AppleSwift. --Ben -- 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 0015643]: Control includes order of project being configured
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15643 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15643 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-08 20:49 CEST Last Modified: 2015-07-08 20:49 CEST == Summary:Control includes order of project being configured Description: A buildsystem can contain target_link_libraries(foo PRIVATE Vendor1::Dep Vendor2::OtherDep ) I might have otherdep installed in /opt, such that /opt/otherdep/include/otherdep.h exists. The 'dep' dependency might be provided in /usr or /usr/local. I can run cmake with various settings such as CMAKE_PREFIX_PATH or OtherDep_DIR to find otherdep in the correct location. The 'foo' target will be compiled with -I/opt/otherdep/include However, if otherdep headers are also installed in /usr or /usr/local, that -I path will not be used to find the headers, and 'foo' will be miscompiled. There is no generic solution to this. If upstream changes the order of the IMPORTED targets, downstreams with 'dep' in /opt will have the problem instead. This problem is more-common on platforms with package managers which do not split headers into -devel packages, and when using a mixture of libraries which are commonly installed though the package manager (such as Qt), and libraries which are installed outside the package manager using vendor supplied packages (such as Qt). It can be reproduced by installing devel packages on linux too. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52883/focus=52895 Perhaps a variable could be introduced to set priority of IMPORTED targets when running cmake. This is an issue local to each actor building the project. == Issue History Date ModifiedUsername FieldChange == 2015-07-08 20:49 Stephen Kelly New Issue == -- 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 Wed, Jul 08, 2015 at 14:11:44 -0400, David Cole wrote: > Interesting. So, sort of, but not really. At least not explicitly. Well, the docs state it, but there's no error for setting CMP0010 OLD and CMP0053 NEW at the same time other than the CMP0053 parser turning any code which would have required CMP0010 into a parse error (and it warns about the two parsers disagreeing if CMP0053 is the default). > I'm still interested in seeing an example commit (even if it's only > theoretical and will never actually be merged in) whose explicit > purpose is removing the OLD behavior of a single policy. (Is there > such a commit which removed the OLD behavior of CMP0010, or is it too > entwined in the parser improvement commits from the 3.1 release cycle > as to be easily identifiable as a concise diff?) My initial attempt at the new parser removed the parser entirely (5000+ lines removed :D ), but it has too many corner cases (allowed escape sequences, CMP0010, and others; look at the tests which came with CMP0053 for a taste). --Ben -- 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] Adding Swift support to CMake
On 07/08/2015 02:35 PM, Stephen Kelly wrote: > "Since Apple is the only vendor implementing the language > right now, the compiler id can be just `Apple`." Even if another vendor implements it the one we're identifying will still be provided by "Apple". The above wording was poor. > This seems somehow wrong. Naming it based on some state 'right now' doesn't > seem future proof. The 'MSVC' compiler id is not called 'Microsoft', the > 'QCC' compiler id is not called 'QNX', 'XL' is not called 'IBM'. The PGI compiler id is "PGI". The PathScale compiler id is "PathScale". The TI compiler id is "TI". The GNU compiler id is "GNU". The Cray compiler id is "Cray". The Absoft compiler id is "Absoft". There is plenty of precedent to use the vendor name. -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] Adding Swift support to CMake
Brad King wrote: > On 07/02/2015 07:54 PM, Eric Wing wrote: >> Thank you Brad. When you are ready, let me know how I can help next. > > I have basic support with the Xcode generator done. > > Please try out this commit: > > Add rudimentary support for the Apple Swift language with Xcode > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531 "Since Apple is the only vendor implementing the language right now, the compiler id can be just `Apple`." This seems somehow wrong. Naming it based on some state 'right now' doesn't seem future proof. The 'MSVC' compiler id is not called 'Microsoft', the 'QCC' compiler id is not called 'QNX', 'XL' is not called 'IBM'. Is there a better name? 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] Patch to fix incorrect paths in Eclipse CDT generator under Cygwin
On 07/08/2015 12:50 PM, Markus Grech wrote: > I've attached a patch to fix a bug in the Eclipse CDT generator under Cygwin. Applied, thanks: Eclipse: Fix paths in target links on cygwin http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a672b16a -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] OBJECT library on left-hand-side of target_link_libraries
On Wed, Jul 08, 2015 at 19:53:31 +0200, Tamás Kenéz wrote: > Is this restriction, that an OBJECT library can't be on the left hand side > of > target_link_libraries, is it a hard, final decision? Or is this issue > open for a possible improvement which would allow this and would forward > the link dependencies to the main target the OBJECT library is incorporated > into? I started a branch to do this, but it is a deep rabbit hole. See this thread: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12509 Development to fix this would be accepted; I'll try and write up the requirements/features Brad and I figured out later today. --Ben -- 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
Interesting. So, sort of, but not really. At least not explicitly. I'm still interested in seeing an example commit (even if it's only theoretical and will never actually be merged in) whose explicit purpose is removing the OLD behavior of a single policy. (Is there such a commit which removed the OLD behavior of CMP0010, or is it too entwined in the parser improvement commits from the 3.1 release cycle as to be easily identifiable as a concise diff?) Weird are the things interesting to geeks, right? Thx, David C. On Wed, Jul 8, 2015 at 10:34 AM, Ben Boeckel wrote: > On Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote: >> Is there a single example of a policy wherein the OLD behavior has >> actually been removed? > > Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it > as NEW (because the new parser doesn't implement the OLD behavior at > all). But CMP0010 is one of those "almost assuredly a bug" policies and > really easy to fix (just escape the '$' or add the closing '}'). > > --Ben -- 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] OBJECT library on left-hand-side of target_link_libraries
The documentation states that OBJECT libraries "may not be [...] used in the
right hand side of target_link_libraries()".
However it turns out that they can't be used on the left hand side either:
add_library(objlib OBJECT ...)
target_link_libraries(objlib dep-of-objlib)
Result:
CMake Error at CMakeLists.txt:13 (target_link_libraries):
Object library target "objlib" may not link to anything.
This makes it impossible to concisely specify if an OBJECT library has a
dependency which is an IMPORTED library.
Only the legacy way works:
add_library(objlib OBJECT ...)
target_include_directories(objlib ${ZLIB_INCLUDE_DIRS})
...
add_executable(maintarget $)
target_link_libraries(maintarget ${ZLIB_LIBRARIES})
But it would be convenient if this would also work:
add_library(objlib OBJECT ...)
target_link_libraries(objlib ZLIB::ZLIB)
Question:
Is this restriction, that an OBJECT library can't be on the left hand side
of
target_link_libraries, is it a hard, final decision? Or is this issue
open for a possible improvement which would allow this and would forward
the link dependencies to the main target the OBJECT library is incorporated
into?
Tamas
--
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] Patch to fix incorrect paths in Eclipse CDT generator under Cygwin
I've attached a patch to fix a bug in the Eclipse CDT generator under Cygwin. The generator would generate invalid links for source files under "[Targets]", making Eclipse unable to open them. The old links look like "C:/cygdrive/c/...", while new links correctly are "C:/...". Markus 0001-Fixed-generation-of-incorrect-paths-for-target-links.patch Description: Binary data -- 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] [PATCH] Extended Nsight Tegra support for CMake
Hi, all! I've extended the Nsight Tegra project generator in CMake and added a bunch of properties with the backing variables to fine-tune the generated projects. The patch adds the following new Target properties: A new Target properties that maps to all "Configuration" PropertyGroups for each configuration defined for Target: ANDROID_ARCH ANDROID_STL_TYPE A new Target properties that maps to AntBuild section in generated Visual Studio project file: ANDROID_ANT_ADDITIONAL_OPTIONS ANDROID_ASSETS_DIRECTORIES ANDROID_JAR_DEPENDENCIES ANDROID_JAR_DIRECTORIES ANDROID_JAVA_SOURCE_DIR ANDROID_NATIVE_LIB_DEPENDENCIES ANDROID_NATIVE_LIB_DIRECTORIES ANDROID_PROCESS_MAX ANDROID_PROGUARD ANDROID_PROGUARD_CONFIG_PATH ANDROID_SECURE_PROPS_PATH ANDROID_SKIP_ANT_STEP Comments and suggestions is welcome, thanks in advance. -Mikhail --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ExtendedNsightTegraSupport.patch Description: ExtendedNsightTegraSupport.patch -- 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] [PATCH] Macro generation for relaxed constexpr
Hello,
At the ned of this mail is a patch that adds generation of a macro for
the relaxed ("c++14") constexpr in WriteCompilerDetectionHeader.
This is intended for compilers that support c++11 constexpr (with
everything on a single return statement) like GCC-4.9 and the upcoming
MSVC, but not extended constexpr which allows for more complete
functions. This way, code bases can reap the benefits of most recent
compilers at no cost.
Best regards
Jean-Michaël Celerier
diff --git a/Modules/WriteCompilerDetectionHeader.cmake
b/Modules/WriteCompilerDetectionHeader.cmake
index a3b73bb..f7af7ec 100644
--- a/Modules/WriteCompilerDetectionHeader.cmake
+++ b/Modules/WriteCompilerDetectionHeader.cmake
@@ -144,6 +144,7 @@
# == ===
=
# ``c_restrict`` ``_RESTRICT`` ``restrict``
# ``cxx_constexpr`` ``_CONSTEXPR`` ``constexpr``
+# ``cxx_relaxed_constexpr`` ``_RELAXED_CONSTEXPR`` ``constexpr``
# ``cxx_deleted_functions`` ``_DELETED_FUNCTION`` ``= delete``
# ``cxx_extern_templates````_EXTERN_TEMPLATE````extern``
# ``cxx_final`` ``_FINAL`` ``final``
@@ -494,6 +495,16 @@ function(write_compiler_detection_header
# endif
\n")
endif()
+ if (feature STREQUAL cxx_relaxed_constexpr)
+set(def_value "${prefix_arg}_RELAXED_CONSTEXPR")
+set(file_content "${file_content}
+# if ${def_name}
+#define ${def_value} constexpr
+# else
+#define ${def_value}
+# endif
+\n")
+ endif()
if (feature STREQUAL cxx_final)
set(def_value "${prefix_arg}_FINAL")
set(file_content "${file_content}
--
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 Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote: > Is there a single example of a policy wherein the OLD behavior has > actually been removed? Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it as NEW (because the new parser doesn't implement the OLD behavior at all). But CMP0010 is one of those "almost assuredly a bug" policies and really easy to fix (just escape the '$' or add the closing '}'). --Ben -- 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 0015642]: empty if case of drive letter changes
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15642 == Reported By:Martin Sander Assigned To: == Project:CMake Issue ID: 15642 Category: (No Category) Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-07-08 10:13 EDT Last Modified: 2015-07-08 10:13 EDT == Summary: empty if case of drive letter changes Description: If cmake is used within cmd.exe and a dependency in add_custom_command(...) has an upper case drive letter and this files occurs otherwise with a lower case drive letter, all tags refererring to the containing directory are empty. The difference is produced with Archive.zip:cmakeBugHunting/build/ttt.bat and visible in Archive.zip:diff.png == Issue History Date ModifiedUsername FieldChange == 2015-07-08 10:13 Martin Sander New Issue 2015-07-08 10:13 Martin Sander File Added: Archive.zip == -- 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] fix use of CMAKE_REQUIRED_DEFINITIONS
On 02/24/2015 09:47 AM, Brad King wrote: > On 02/24/2015 08:25 AM, Mark Abraham wrote: >> Some modules shoud use CMAKE_REQUIRED_FLAGS, not CMAKE_REQUIRED_DEFINITIONS, >> I think. > > Actually both technically support any flags, but the latter > only for legacy reasons. I agree CMAKE_REQUIRED_FLAGS is > clearer for this purpose. I've applied the patch with > minor tweaks: > > Check*CompilerFlag: Refactor method used to pass flags > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d5067ae We need to revert this change from 3.3 because it caused a regression: In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags https://public.kitware.com/Bug/view.php?id=15641 See issue tracker entry for further updates. -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] AppleClang-CXX.cmake needs an update
On 07/08/2015 03:08 AM, darkapos...@rule506.net wrote: > C++14 is a first class citizen in Xcode 6. Applied, thanks: AppleClang: Use modern C++14 standard flags for Xcode 6 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0430c0a -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 0015641]: In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags
The following issue has been SUBMITTED.
==
https://public.kitware.com/Bug/view.php?id=15641
==
Reported By:Nikolay Zapolnov
Assigned To:
==
Project:CMake
Issue ID: 15641
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-07-08 09:27 EDT
Last Modified: 2015-07-08 09:27 EDT
==
Summary:In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is
broken on OSX for some flags
Description:
In CMake 3.2.3 the CHECK_CXX_COMPILER_FLAG macro launches compiler and then
linker.
But tested flag is passed *only* to the compiler and test passes.
But in CMake 3.3.0-rc3 argument is passed to *both* the compiler and the linker.
This causes an error for some flags, for example for '-x objective-c++'. Passing
this flag to the linker makes it recognize .o files as objective-c++ sources and
fail.
Steps to Reproduce:
Use the following CMakeLists.txt
INCLUDE(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG("-x objective-c++" HAVE_OBJC)
This will work correctly in CMake 3.2.3 but in CMake 3.3.0-rc3 HAVE_OBJC will be
always false.
Additional Information:
Part of CMakeOutput.log for good case and part of CMakeError.log for broken case
are attached to the ticket.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-08 09:27 Nikolay ZapolnovNew Issue
2015-07-08 09:27 Nikolay ZapolnovFile Added: good-cmake322.log
==
--
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] AppleClang-CXX.cmake needs an update
C++14 is a first class citizen in Xcode 6. *diff --git a/Modules/Compiler/AppleClang-CXX.cmake b/Modules/Compiler/AppleClang- CXX.cmake* *index 5194da4..27e4d8a 100644* *--- a/Modules/Compiler/AppleClang-CXX.cmake* *+++ b/Modules/Compiler/AppleClang-CXX.cmake* @@ -13,7 +13,10 @@ if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.0) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION "-std=gnu++11") endif() -if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1) +if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 6.0) + set(CMAKE_CXX14_STANDARD_COMPILE_OPTION "-std=c++14") + set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION "-std=gnu++14") +elseif(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 5.1) # AppleClang 5.0 knows this flag, but does not set a __cplusplus macro greater than 201103L set(CMAKE_CXX14_STANDARD_COMPILE_OPTION "-std=c++1y") set(CMAKE_CXX14_EXTENSION_COMPILE_OPTION "-std=gnu++1y") AppleClang-CXX.cmake.diff Description: Binary data -- 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
