Notes |
|
(0033665)
|
Brad King
|
2013-08-05 09:28
|
|
This module is inherently difficult to implement and cannot be guaranteed. Every compiler behaves differently w.r.t. unknown compiler flags, and the behavior is often dependent on the flag.
In this case:
$ xlc -std=cxx11 foo.c
xlc: 1501-210 (W) command option t contains an incorrect subargument
...
>bcc32 -std=cxx11 foo.c
(no complaint)
but for another bogus option:
$ xlc -1 foo.c
xlc: 1501-216 (W) command option -1 is not recognized - passed to ld
ld: 0706-012 The -1 flag is not recognized.
>bcc32 -1 foo.c
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Error E2075: Incorrect command line option: -1
|
|
|
(0033684)
|
Brad King
|
2013-08-08 11:01
|
|
The wcl386 compiler help shows
-st touch stack through SS first
and using -std=cxx11 results in
Error! E059: unable to open 'd=c++11' |
|
|
(0033687)
|
Rolf Eike Beer
|
2013-08-08 16:52
|
|
The difficulty of this makes it even more important that we get this right, the average user will have even more problems to get this right and will even less likely have the possibility to check this on different compilers. |
|
|
(0033688)
|
Rolf Eike Beer
|
2013-08-08 17:51
|
|
Pushed my patch to next, this will hopefully fix at least the XL misdetection. |
|
|
(0033691)
|
Brad King
|
2013-08-09 08:43
|
|
Thanks for working on this. While at it, please ensure that the C and CXX modules are maintained together. Actually perhaps some refactoring is in order as the two are almost identical and repeat the matching expressions. The only language-specific expression is the "...but not for C" for GNU. |
|
|
(0033692)
|
Brad King
|
2013-08-09 08:44
|
|
The problem with these modules in general is that the detection needs to be flag-specific. Just because a compiler accepts a flag without error does not mean it does what the project expects. The modules' documentation should be updated to mention this caveat. |
|
|
(0033695)
|
Rolf Eike Beer
|
2013-08-10 15:31
|
|
I have pushed the topic "cxx-flags" to next which merges most of the pattern. |
|
|
(0033696)
|
Rolf Eike Beer
|
2013-08-10 15:32
|
|
Did you really mean to set this to backlog? |
|
|
(0033697)
|
Rolf Eike Beer
|
2013-08-10 15:35
|
|
How about adding this text at the end of the doc for both modules:
# The result only tells that the compiler does not give an error message when
# it encounters the flag. If the flag has any effect or even a specific one is
# beyond the scope of this module. |
|
|
(0033705)
|
Brad King
|
2013-08-13 09:40
|
|
Re 0014339:0033695: The topic includes this hunk:
+function (CHECK_CXX_COMPILER_FLAG_COMMON_PATTERNS _VAR)
+ include(${CMAKE_CURRENT_LIST_DIR}/CheckCCompilerFlag.cmake)
Including a file from inside a function has funky scoping rules, so please avoid doing so in this case.
Re 0014339:0033697: Yes, that documentation disclaimer looks good. |
|
|
(0033707)
|
Rolf Eike Beer
|
2013-08-13 09:53
|
|
That include from inside the function was intentional to avoid the check_c_* stuff from being visible to the outside when anyone includes check_cxx_*. The idea was to force people to still include check_c_* if they need it and not accidentially get it from check_cxx_*. |
|
|
(0033708)
|
Brad King
|
2013-08-13 09:58
|
|
Re 0014339:0033707: Instead move the common patterns to a separate detail module that is not publicly documented and include that from both. |
|
|
(0033709)
|
Rolf Eike Beer
|
2013-08-13 15:19
|
|
Ok, done. From my side I think the topic can be merged now. |
|
|
(0036953)
|
Robert Maynard
|
2014-10-06 10:33
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|