[cmake-developers] [CMake 0012401]: Find OpenCL module
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12401 == Reported By:Mazhe Assigned To: == Project:CMake Issue ID: 12401 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2011-08-13 05:06 EDT Last Modified: 2011-08-13 05:06 EDT == Summary:Find OpenCL module Description: As of now, there is no module to find an installed OpenCL implementation. I wrote a small but working FindOpenCL.cmake file that was tested for a few Linux distributions (Fedora, Ubuntu) and MacOSX 10.6. I'd like to propose it for inclusion in the modules present by default in CMake. Cheers, -- Matthieu Volat Additional Information: License is the two-clauses BSD, but I can donate the file under the three-clauses to better match CMake's own license. == Issue History Date ModifiedUsername FieldChange == 2011-08-13 05:06 Mazhe New Issue 2011-08-13 05:06 Mazhe File Added: FindOpenCL.cmake == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Fwd: [CMake 0012398]: IF infamous variable/string functionality fails to work with macro arguments
For most users, macros should be a taboo anyways. They are much better
served by functions, IMHO. In all of my projects I had only one case
where I actually needed a macro. That was when I wrapped a function
that set some variables in the PARENT_SCOPE and I had to propagate them
outside of the wrapping macro without knowing their name.
Perhaps it would be enough to just properly document the quirky
behaviour of macro arguments in the docs and mention that one should
normally prefer functions over macros unless there is a real reason
that requires a macro?
Michael
On Fri 12 Aug 2011 09:29:21 PM CEST, David Cole wrote:
Does anybody here on the list have an opinion one way or the other on
whether it's worth pursuing a fix to this re-opened bug regarding
CMake macro and if command behavior...?
Thanks for any input, either here on the list, or directly in the bug
notes themselves.
Thanks,
David
-- Forwarded message --
From: Mantis Bug Tracker man...@public.kitware.com
Date: Fri, Aug 12, 2011 at 2:49 PM
Subject: [CMake 0012398]: IF infamous variable/string
functionality fails to work with macro arguments
To: david.c...@kitware.com
The following issue has been REOPENED.
==
http://public.kitware.com/Bug/view.php?id=12398
==
Reported By:freddie
Assigned To:David Cole
==
Project:CMake
Issue ID: 12398
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: feedback
==
Date Submitted: 2011-08-12 08:13 EDT
Last Modified: 2011-08-12 14:49 EDT
==
Summary:IF infamous variable/string functionality
fails
to work with macro arguments
Description:
There is a problem with the IF command when it is used directly with macro
arguments. Apparently, they are not considered variables and are used directly
as strings.
However, if their contents can be construed as variables themselves (even
though
it is not desired), we have a problem when the only way to perform the test is
to create another explicit variable assigning it to what the macro argument
contains.
The problem doesn't appear to pertain to functions.
Steps to Reproduce:
Please use the attached CMakeLists.txt file with cmake -Wno-dev ..
Additional Information:
It would really be a good idea to create a version of if/elseif/else/endif
which
does NOT attempt to treat its arguments as variables, either by creating a new
name for the command or, better yet, by adding a new policy (possibly not
associated with a version yet).
Otherwise, when trying to compare things which might be variables but should
not
be treated as such for the purposes of the comparison, one runs into subtle
problems (when checks randomly fail) or has to create a level of
indirection,
by setting a new variable just for that.
I am sure you've heard this all before.
==
Relationships ID Summary
--
duplicate of0009590 IF(VARIABLE) doesn't work inside Makro
==
--
(0027199) freddie (reporter) - 2011-08-12 14:49
http://public.kitware.com/Bug/view.php?id=12398#c27199
--
Your comparison of macro with preprocessor macros makes sense. If only it
worked
that way. In cmake language, ${foo} expands a variable; if ARGV0 is not a
variable, then you must either substitute ARGV0 for what was specified in the
parameter list for the macro, or use a different expansion {#{ARGV0}, for
instance); otherwise, people who can't be called stupid will keep running into
these problems.
However, the analogy stops there; FUNCTION is not equivalent to functions or
methods in C/C++ in the sense that variables are automatically local to the
function, and setting a variable in a different scope is problematic. If I
have
a directory-specific variable that I set and append to in multiple places (I'd
call it namespace-specific), I can't use it here because it's hard to say how
many parent-scope levels up it is. So we end up using macros.
And about IF: I am not sure about this worth the effort statement. This
behaviour is quite unusual (I don't know of any other language that does this)
Re: [CMake] append command
Out of all the suggestions so far I'd like to say that my preferred solution
is Michael's one of:
SET(variable value ... CONCAT [SEP sep])
I haven't seen any discussion yet of my 2nd alternative of getting cmake to
automatically convert lists to space separated strings for certain variables
like CMAKE_EXE_LINKER_FLAGS_RELEASE. If cmake did this then there would be
less need for the concat version of set() as one could just use the existing
list(APPEND) functionality. Is this a realistic possibility, or are there
implementation issues with this suggestion ?
--
Glenn
On 12 August 2011 05:16, Michael Hertling mhertl...@online.de wrote:
On 08/11/2011 10:04 PM, Alexander Neundorf wrote:
On Thursday 11 August 2011, Michael Hertling wrote:
...
Alternatively, one might consider to introduce a new, say,
modifier CONCAT for the SET() command, e.g.
SET(variable value ... CONCAT [SEP sep])
equivalent to
SET(variable ${variable}sepvalue...)
I'm not sure this is actually necessary.
Personally I'm fine with
set(foo ${foo} bar)
It's just one line. For properties more code is needed otherwise.
So far, I also don't need such a string concatenation feature, but
LIST(APPEND ...)
and
SET_PROPERTY(... APPEND/APPEND_STRING ...)
aren't actually necessary, too, but convenient, so I would not be
opposed to another convenience feature for concatenating strings.
Besides, David, due to the same reasons as mentioned above, the new
APPEND_STRING subcommand of SET_PROPERTY() is quite misnamed, IMO -
and quite long. Would it be possible to rename it to CONCAT before
it is released officially? In this way, we would consistently have
APPEND subcommands for list-style variables/properties and CONCAT
subcommands for string-style ones.
We can do that, if other people think also that this would be a better
name.
Or STRING_APPEND instead of APPEND_STRING ?
The crucial point is that the subcommand/modifier for concatenating
strings - regardless for which command(s) it is implemented - should
- not be named APPEND because this term is already in use for lists,
and there's at least one occasion where a list-related and a string-
related += operation are about to coincide, namely SET_PROPERTY().
- be named the same in all commands that provide - or possibly will
provide - this functionality. SET_PROPERTY() is going to name it
APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
result in inconsistent CMakeLists.txt code if there'll be a SET()
or STRING() implementation for concatenating strings: Certainly,
one would not want to call the latter SET(... APPEND_STRING) or
STRING(STRING_APPEND ...), so one ends up with two differently
named subcommands/modifiers for the same kind of operation.
For this reason, I'd recommend to reconsider the APPEND_STRING sub-
command's naming and change it to a term that's also suitable for
a string concatenation feature in other CMake commands - just to
leave the door open. Therefor, my suggestion is CONCAT.
Regards,
Michael
___
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://www.cmake.org/mailman/listinfo/cmake
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
On Sat 13 Aug 2011 11:14:52 AM CEST, Glenn Coombs wrote:
Out of all the suggestions so far I'd like to say that my preferred
solution is Michael's one of:
SET(variable value ... CONCAT [SEP sep])
I haven't seen any discussion yet of my 2nd alternative of getting cmake
to automatically convert lists to space separated strings for certain
variables like CMAKE_EXE_LINKER_FLAGS_RELEASE. If cmake did this then
there would be less need for the concat version of set() as one could
just use the existing list(APPEND) functionality. Is this a realistic
possibility, or are there implementation issues with this suggestion ?
--
Glenn
On 12 August 2011 05:16, Michael Hertling mhertl...@online.de
mailto:mhertl...@online.de wrote:
On 08/11/2011 10:04 PM, Alexander Neundorf wrote:
On Thursday 11 August 2011, Michael Hertling wrote:
...
Alternatively, one might consider to introduce a new, say,
modifier CONCAT for the SET() command, e.g.
SET(variable value ... CONCAT [SEP sep])
equivalent to
SET(variable ${variable}sepvalue...)
I'm not sure this is actually necessary.
Personally I'm fine with
set(foo ${foo} bar)
It's just one line. For properties more code is needed otherwise.
So far, I also don't need such a string concatenation feature, but
LIST(APPEND ...)
and
SET_PROPERTY(... APPEND/APPEND_STRING ...)
aren't actually necessary, too, but convenient, so I would not be
opposed to another convenience feature for concatenating strings.
Besides, David, due to the same reasons as mentioned above, the new
APPEND_STRING subcommand of SET_PROPERTY() is quite misnamed, IMO -
and quite long. Would it be possible to rename it to CONCAT before
it is released officially? In this way, we would consistently have
APPEND subcommands for list-style variables/properties and CONCAT
subcommands for string-style ones.
We can do that, if other people think also that this would be a
better name.
Or STRING_APPEND instead of APPEND_STRING ?
The crucial point is that the subcommand/modifier for concatenating
strings - regardless for which command(s) it is implemented - should
- not be named APPEND because this term is already in use for lists,
and there's at least one occasion where a list-related and a string-
related += operation are about to coincide, namely SET_PROPERTY().
- be named the same in all commands that provide - or possibly will
provide - this functionality. SET_PROPERTY() is going to name it
APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
result in inconsistent CMakeLists.txt code if there'll be a SET()
or STRING() implementation for concatenating strings: Certainly,
one would not want to call the latter SET(... APPEND_STRING) or
STRING(STRING_APPEND ...), so one ends up with two differently
named subcommands/modifiers for the same kind of operation.
For this reason, I'd recommend to reconsider the APPEND_STRING sub-
command's naming and change it to a term that's also suitable for
a string concatenation feature in other CMake commands - just to
leave the door open. Therefor, my suggestion is CONCAT.
Regards,
Michael
To be honest, the only occasion where I miss a more concise command is
when I have pretty long variable names and it becomes essentially
impossible to stay within a 80-columns line length limit.
Michael
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
Which is precisely the sort of thing that started this whole discussion :-) In the same way that C/C++ would still work without the += operator it does allow a wonderful conciseness that I miss on occasion. Especially given cmake's propensity for verbose variable names. On 13 August 2011 10:22, Michael Wild them...@gmail.com wrote: To be honest, the only occasion where I miss a more concise command is when I have pretty long variable names and it becomes essentially impossible to stay within a 80-columns line length limit. Michael ___ 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://www.cmake.org/mailman/listinfo/cmake ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
On Sat, Aug 13, 2011 at 5:14 AM, Glenn Coombs glenn.coo...@gmail.com wrote: I haven't seen any discussion yet of my 2nd alternative of getting cmake to automatically convert lists to space separated strings for certain variables like CMAKE_EXE_LINKER_FLAGS_RELEASE. If cmake did this then there would be less need for the concat version of set() as one could just use the existing list(APPEND) functionality. Is this a realistic possibility, or are there implementation issues with this suggestion ? This surprised me as well - if you want to assemble a list of flags on the fly (I needed to assemble lists of lists of flags - we pass a lot of them) you have to take some care to either do the set trick correctly or convert the list to a string at the end (if you can be sure of where that is). Do I understand correctly that the main concern is the ability to pass args with ;' characters in these cases? Then the question becomes whether quoting ; characters as needed in user-specified options is tricker than navigating the current behavior. To be honest, I can see where trying to specify an argument with a quoted ; character from the command line would get a bit messy (in a ok, how do I quote this from this enviornment sort of way) - how common are ; characters as components of variable values? Cheers, CY ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
I just wrote my own macro append_property(type name value) for this. example: append_property(SOURCE COMPILE_FLAGS -x objective-c++ translate.cpp stuff.cpp) or append_property(TARGET COMPILE_FLAGS foo mytarget) etc Would be nice to have that as an included macro, or at least a comment in the documentation about what happens when you pass in a list. /Johan On Sat, Aug 13, 2011 at 8:57 PM, Clifford Yapp cliffy...@gmail.com wrote: On Sat, Aug 13, 2011 at 5:14 AM, Glenn Coombs glenn.coo...@gmail.com wrote: I haven't seen any discussion yet of my 2nd alternative of getting cmake to automatically convert lists to space separated strings for certain variables like CMAKE_EXE_LINKER_FLAGS_RELEASE. If cmake did this then there would be less need for the concat version of set() as one could just use the existing list(APPEND) functionality. Is this a realistic possibility, or are there implementation issues with this suggestion ? This surprised me as well - if you want to assemble a list of flags on the fly (I needed to assemble lists of lists of flags - we pass a lot of them) you have to take some care to either do the set trick correctly or convert the list to a string at the end (if you can be sure of where that is). Do I understand correctly that the main concern is the ability to pass args with ;' characters in these cases? Then the question becomes whether quoting ; characters as needed in user-specified options is tricker than navigating the current behavior. To be honest, I can see where trying to specify an argument with a quoted ; character from the command line would get a bit messy (in a ok, how do I quote this from this enviornment sort of way) - how common are ; characters as components of variable values? Cheers, CY ___ 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://www.cmake.org/mailman/listinfo/cmake ___ 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.5-1541-gdbdd8ec
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via dbdd8ec53e935a67bf9f60964f3971e0c76eecea (commit)
via fd15b5e1c425b0e2cb418e87a115215b0aa7501a (commit)
via 9fc87c6343a5d448f04d7a9397beb95e3b85178e (commit)
via d3ae0fff7dea00775f8c6e8bed59a494f102999c (commit)
via bf0737526419936915a9f2c14f06bff556d1fcd4 (commit)
via b0e357824c0ddf1a57db7742da3d5f3f90af97d2 (commit)
via 53edfb206b549f0dd5a014aac054ca82d865bbcd (commit)
via b8fdaa1d662b01a167c94f2a9a9efec9dd0ea2d0 (commit)
via 7690edffd9801c41dcfa4ef2a6213d4883e55c83 (commit)
via e4f603b698a13857e79a5f6df18a7461b20d4bd4 (commit)
via a91d662f46fd2781fc5a3b73c2d244ac6dc2a343 (commit)
via b976e70063008c0633cb5dd4ecb1f40278c67935 (commit)
from f864aa4885c1e40c88f77d02edac36402a2d6a36 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dbdd8ec53e935a67bf9f60964f3971e0c76eecea
commit dbdd8ec53e935a67bf9f60964f3971e0c76eecea
Merge: f864aa4 fd15b5e
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Sat Aug 13 17:13:42 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Aug 13 17:13:42 2011 -0400
Merge topic 'UsingCMakeLikePkgConfig2' into next
fd15b5e Only run the test if we are using a makefile generator under UNIX
9fc87c6 Add a test for the new --find-package mode
d3ae0ff Improve documentation for --find-package mode
bf07375 Add a cmake.m4 for using cmake in autoconf projects instead of
pkgconfig
b0e3578 Use the file-utility to test for 64bit if there is no /usr/lib64
53edfb2 Better support for lib64 and Debian multiarch
b8fdaa1 Fix copyright notice in new CMakeFindPackageMode.cmake
7690edf Replace cmake::GetScriptMode() with GetWorkingMode()
e4f603b Implement find-package mode of cmake
a91d662 Add find-package mode, which does nothing yet
b976e70 Make clLocalGenerator::GetTargetFlags() public
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd15b5e1c425b0e2cb418e87a115215b0aa7501a
commit fd15b5e1c425b0e2cb418e87a115215b0aa7501a
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Aug 11 23:32:30 2011 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Aug 11 23:34:25 2011 +0200
Only run the test if we are using a makefile generator under UNIX
Alex
diff --git a/Tests/FindPackageModeMakefileTest/CMakeLists.txt
b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
index 0be3783..f0faab9 100644
--- a/Tests/FindPackageModeMakefileTest/CMakeLists.txt
+++ b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
@@ -8,7 +8,7 @@ if(${CMAKE_CXX_COMPILER_ID} MATCHES GNU
find_package(PNG)
# the test program links against the png lib, so test first whether it exists
- if(PNG_FOUND)
+ if(PNG_FOUND AND UNIX AND ${CMAKE_GENERATOR} MATCHES Makefile)
get_target_property(cmakeExecutable cmake LOCATION)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9fc87c6343a5d448f04d7a9397beb95e3b85178e
commit 9fc87c6343a5d448f04d7a9397beb95e3b85178e
Author: Alex Neundorf neund...@kde.org
AuthorDate: Thu Aug 11 23:27:19 2011 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Thu Aug 11 23:34:17 2011 +0200
Add a test for the new --find-package mode
Alex
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 2ad9a77..a75b3df 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -46,6 +46,8 @@ IF(BUILD_TESTING)
ADD_SUBDIRECTORY(CMakeLib)
+ ADD_SUBDIRECTORY(FindPackageModeMakefileTest)
+
# Collect a list of all test build directories.
SET(TEST_BUILD_DIRS)
diff --git a/Tests/FindPackageModeMakefileTest/CMakeLists.txt
b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
new file mode 100644
index 000..0be3783
--- /dev/null
+++ b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
@@ -0,0 +1,22 @@
+
+if(${CMAKE_CXX_COMPILER_ID} MATCHES GNU
+ OR ${CMAKE_CXX_COMPILER_ID} MATCHES Intel
+ OR ${CMAKE_CXX_COMPILER_ID} MATCHES Clang
+ OR ${CMAKE_CXX_COMPILER_ID} MATCHES XL
+ OR ${CMAKE_CXX_COMPILER_ID} MATCHES SunPro)
+
+ find_package(PNG)
+
+ # the test program links against the png lib, so test first whether it exists
+ if(PNG_FOUND)
+
+get_target_property(cmakeExecutable cmake LOCATION)
+
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/Makefile.in
${CMAKE_CURRENT_BINARY_DIR}/ConfMakefile @ONLY)
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/main.cpp
${CMAKE_CURRENT_BINARY_DIR}/main.cpp COPYONLY)
+
+add_test(FindPackageModeMakefileTest ${CMAKE_MAKE_PROGRAM} -f
[Cmake-commits] CMake branch, next, updated. v2.8.5-1546-ga8ce92a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a8ce92abf0226cde3a55a440ff4b34897c99f475 (commit)
via 2aeab4f973144fe859d5751e969512a92ae08d96 (commit)
via c41c68bfa437d4ea1b2ae5153f6f20430c47d902 (commit)
via aed84517c942a4c40f493fcf997cdf6a047349f8 (commit)
via c448b09ad39c35b129d7b91710bea4f26fabdfe4 (commit)
from dbdd8ec53e935a67bf9f60964f3971e0c76eecea (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a8ce92abf0226cde3a55a440ff4b34897c99f475
commit a8ce92abf0226cde3a55a440ff4b34897c99f475
Merge: dbdd8ec 2aeab4f
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Aug 13 17:51:08 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Aug 13 17:51:08 2011 -0400
Merge topic 'generate_export_header' into next
2aeab4f Borland can't do deprecated.
c41c68b Try to error on deprecated on Intel and SunCC.
aed8451 Test for deprecated attribute before declspec.
c448b09 Perform the -Werror test only once.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2aeab4f973144fe859d5751e969512a92ae08d96
commit 2aeab4f973144fe859d5751e969512a92ae08d96
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Aug 13 23:30:35 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Sat Aug 13 23:49:17 2011 +0200
Borland can't do deprecated.
diff --git a/Modules/GenerateExportHeader.cmake
b/Modules/GenerateExportHeader.cmake
index 044e2b4..5b42b77 100644
--- a/Modules/GenerateExportHeader.cmake
+++ b/Modules/GenerateExportHeader.cmake
@@ -158,11 +158,15 @@ macro(_test_compiler_hidden_visibility)
endmacro()
macro(_test_compiler_has_deprecated)
- _check_cxx_compiler_attribute(__attribute__((__deprecated__))
COMPILER_HAS_DEPRECATED_ATTR)
- if(COMPILER_HAS_DEPRECATED_ATTR)
-set(COMPILER_HAS_DEPRECATED ${COMPILER_HAS_DEPRECATED_ATTR} CACHE
INTERNAL Compiler support for a deprecated attribute)
+ if(${CMAKE_CXX_COMPILER_ID} MATCHES Borland)
+set(COMPILER_HAS_DEPRECATED CACHE INTERNAL Compiler support for a
deprecated attribute)
else()
-_check_cxx_compiler_attribute(__declspec(deprecated)
COMPILER_HAS_DEPRECATED)
+_check_cxx_compiler_attribute(__attribute__((__deprecated__))
COMPILER_HAS_DEPRECATED_ATTR)
+if(COMPILER_HAS_DEPRECATED_ATTR)
+ set(COMPILER_HAS_DEPRECATED ${COMPILER_HAS_DEPRECATED_ATTR} CACHE
INTERNAL Compiler support for a deprecated attribute)
+else()
+ _check_cxx_compiler_attribute(__declspec(deprecated)
COMPILER_HAS_DEPRECATED)
+endif()
endif()
endmacro()
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c41c68bfa437d4ea1b2ae5153f6f20430c47d902
commit c41c68bfa437d4ea1b2ae5153f6f20430c47d902
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sat Aug 13 23:06:01 2011 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Sat Aug 13 23:49:17 2011 +0200
Try to error on deprecated on Intel and SunCC.
diff --git a/Tests/Module/GenerateExportHeader/CMakeLists.txt
b/Tests/Module/GenerateExportHeader/CMakeLists.txt
index 46ab885..dc72689 100644
--- a/Tests/Module/GenerateExportHeader/CMakeLists.txt
+++ b/Tests/Module/GenerateExportHeader/CMakeLists.txt
@@ -20,6 +20,27 @@ endmacro()
check_cxx_compiler_flag(-Werror HAS_WERROR_FLAG)
+if(HAS_WERROR_FLAG)
+ set(ERROR_FLAG -Werror)
+else()
+ # MSVC
+ # And intel on windows?
+ #
http://software.intel.com/en-us/articles/how-to-handle-warnings-message-in-compiler/?wapkw=%28compiler+warning+message%29
+ check_cxx_compiler_flag(/WX HAS_WX_FLAG)
+ if(HAS_WX_FLAG)
+set(ERROR_FLAG /WX)
+ else()
+# Sun CC
+# http://www.acsu.buffalo.edu/~charngda/sunstudio.html
+check_cxx_compiler_flag(-errwarn=%all HAS_ERRWARN_ALL)
+if (HAS_ERRWARN_ALL)
+ set(ERROR_FLAG -errwarn=%all)
+else()
+endif()
+ endif()
+endif()
+
+
# We seem to get race conditions is writing this stuff to the same file at
least on MinGW
# So to write to separate source and build directories, we use a count to
differentiate.
set (COUNT 0)
@@ -50,13 +71,8 @@ macro(_do_build Include Library LibrarySource Source)
add_compiler_export_flags()\n
-if(${HAS_WERROR_FLAG})\n
- add_definitions(-Werror)\n
-else()\n
- if(MSVC AND COMPILER_HAS_DEPRECATED)\n
- # Treat deprecation warnings as errors.
-add_definitions(/we4996)\n
- endif()\n
+if(NOT \${ERROR_FLAG}\ STREQUAL \\)\n
+ add_definitions(${ERROR_FLAG})\n
endif()\n
if(MSVC)\n
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aed84517c942a4c40f493fcf997cdf6a047349f8
commit
