[cmake-developers] [CMake 0012401]: Find OpenCL module

2011-08-13 Thread Mantis Bug Tracker

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] Sub dependencies?

2011-08-13 Thread Michael Wild
On Sat 13 Aug 2011 03:55:06 AM CEST, Doug wrote:
 I see.
 
 I've tried this approach and I get the error:
 -- Found LIBPNG
 CMake Error at CMakeLists.txt:49 (export):
   export given target /usr/lib/libpng.so which is not built by this
   project.
 
 
 -- Configuring incomplete, errors occurred!
 
 ~
 Doug.
 
 On Fri, Aug 12, 2011 at 4:57 PM, Michael Wild them...@gmail.com
 mailto:them...@gmail.com wrote:
 
 On Fri 12 Aug 2011 10:49:45 AM CEST, Doug wrote:
  I'm sorry if I'm being dumb here, but I fail to see how that helps.
 
  That example is one where foobar depends explicitly on foo and bar.
 
  What if foo depends on bar2?
 
  How do I inherit that dependency from foo in foobar?
 
  _that's_ what I'm looking for.
 
  (If that example somehow explains that, I'm sorry, I can't see it. Can
  you point to a specific point in the page?)
 
  ~
  Doug.
 
  On Fri, Aug 12, 2011 at 2:34 PM, Michael Wild them...@gmail.com
 mailto:them...@gmail.com
  mailto:them...@gmail.com mailto:them...@gmail.com wrote:
 
  If the projects are independent, you might want to take a look
 at this
  Wiki page:
 
 
 http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file.
 
  HTH
 
  Michael
 
 
 And that is what the example is *about*. The FooBar project *exports*
 its targets, along with their dependencies, so that when other projects
 do find_package(FooBar), they will be able to link against the foo
 library without having to know any of the dependencies of it. E.g. the
 project hello might look like this:
 
 project(hello)
 find_package(FooBar REQUIRED)
 include_directories(${FOOBAR_INCLUDE_DIRS})
 add_executable(hello hello.c)
 target_link_libraries(hello ${FOOBAR_LIBRARIES})
 
 
 Michael

Did you do something like this?

export(TARGETS /usr/lib/libpng.so)

That would be wrong... You do it like this

find_package(PNG REQUIRED)
add_library(foo SHARED foo.c)
target_link_libraries(foo ${PNG_LIBRARIES})
install(TARGETS foo EXPORT FooLibraryDepends
  RUNTIME DESTINATION bin
  LIBRARY DESTINATION lib)
export(TARGETS foo FILE ${PROJECT_BINARY_DIR}/FooLibraryDepends.cmake)


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] Fwd: [CMake 0012398]: IF infamous variable/string functionality fails to work with macro arguments

2011-08-13 Thread Michael Wild
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

2011-08-13 Thread Glenn Coombs
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

2011-08-13 Thread Michael Wild
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

2011-08-13 Thread Glenn Coombs
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

2011-08-13 Thread Clifford Yapp
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

2011-08-13 Thread Johan Björk
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

2011-08-13 Thread Alexander Neundorf
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

2011-08-13 Thread Stephen Kelly
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