[cmake-developers] [CMake 0013646]: Automoc doesn't recognise "#if QT_VERSION = x" anymore

2012-11-02 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=13646 
== 
Reported By:Dominik Schmidt
Assigned To:
== 
Project:CMake
Issue ID:   13646
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-11-02 17:37 EDT
Last Modified:  2012-11-02 17:37 EDT
== 
Summary:Automoc doesn't recognise "#if QT_VERSION = x"
anymore
Description: 
With the latest release of CMake compilation of Tomahawk Player stopped working
for us because automoc stopped producing output for a certain file.

Obviously code ifdef'ed by "#if QT_VERSION >= 0x040400" isn't scanned anymore.

The commit that fixed building for us:
https://github.com/tomahawk-player/tomahawk/commit/c910e1b58f01a42b9f99222e501172576d8cad06

Steps to Reproduce: 
Put code in "#if QT_VERSION >= 0x040400" and run automoc on it.

Additional Information: 
Of course I'm talking about CMake built in automoc, not automoc4 from KDE.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-11-02 17:37 Dominik SchmidtNew Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013645]: Regression: FindOpenSSL doesn't find anything for MSVC

2012-11-02 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=13645 
== 
Reported By:Thomas Sondergaard
Assigned To:
== 
Project:CMake
Issue ID:   13645
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-11-02 14:23 EDT
Last Modified:  2012-11-02 14:23 EDT
== 
Summary:Regression: FindOpenSSL doesn't find anything for
MSVC
Description: 
The use of select_library_configurations from SelectLibraryConfigurations.cmake
is broken. The variables defined with find_library have the wrong names e.g.
LIB_EAY_DEBUG should be LIB_EAY_LIBRARY_DEBUG.

Also, with MSVC libeay32d.lib and ssleay32d.lib are no longer recognized - only
libeay32MDd.lib and ssleay32MDd
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-11-02 14:23 Thomas SondergaardNew Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013644]: Default pdb output location changed in cmake 2.8.10

2012-11-02 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=13644 
== 
Reported By:Reid Kleckner
Assigned To:
== 
Project:CMake
Issue ID:   13644
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-11-02 10:49 EDT
Last Modified:  2012-11-02 10:49 EDT
== 
Summary:Default pdb output location changed in cmake 2.8.10
Description: 
In the course of adding PDB_OUTPUT_DIRECTORY and related properties and
variables, the default location for pdb files changed.

In our project (DynamoRIO) we have a bunch of targets where we set
RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, etc.  The .pdb file would
get created in ${RUNTIME_OUTPUT_DIRECTORY} next to the .dll, which is what we
want.  After this change, it would get created in the default output directory,
which is different.  Furthermore, this would mean the pdbs never got installed.

Our CMake code:
set_target_properties(dynamorio PROPERTIES
  LIBRARY_OUTPUT_DIRECTORY${location_suffix} "${DR_LIBRARY_OUTPUT_DIRECTORY}"
  RUNTIME_OUTPUT_DIRECTORY${location_suffix} "${DR_LIBRARY_OUTPUT_DIRECTORY}"
  ARCHIVE_OUTPUT_DIRECTORY${location_suffix} "${DR_LIBRARY_OUTPUT_DIRECTORY}"
  # The next line is the one I added to work around the problem.
  #PDB_OUTPUT_DIRECTORY${location_suffix} "${DR_LIBRARY_OUTPUT_DIRECTORY}"
  )

>From the linker command line:
/out:lib32\debug\dynamorio.dll
/implib:lib32\debug\dynamorio.lib
/pdb:core\dynamorio.pdb

We can easily work around the problem by setting PDB_OUTPUT_DIRECTORY as well as
RUNTIME, ARCHIVE, and LIBRARY, but it'd be nice for other users that aren't
using cmake from version control if the default didn't change.

Upstream issue where we figured this out:
http://code.google.com/p/chromium/issues/detail?id=159092

Original issue:
http://www.cmake.org/Bug/view.php?id=10830

CMake commit that made the change:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f60dbf1

Steps to Reproduce: 
1. Create a library target
2. Set the runtime and archive output directory to somewhere non-default
3. Build it
4. Observe that the pdb does not reside next to the dll
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-11-02 10:49 Reid Kleckner  New Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] patch for cmake that adds a new timestamp command

2012-11-02 Thread David Cole 
You're welcome. I decided to wait till the dashboard cleans up again
before merging this topic, but it should be in the next few days.

On Fri, Nov 2, 2012 at 10:19 AM, Nils Gladitz  wrote:
> Thanks!
>
> Let me know if there is anything else I can do.
>
> Nils
>
>
> On 10/31/2012 09:52 PM, David Cole wrote:
>
> Has anybody tried this anywhere else? I'm going to merge it to 'next'
> tomorrow, so that it will get tested on the dashboards after that. Just
> curious if there are any other known problems with it that I should squash
> in before doing that...
>
> Thanks,
> David
>
>
>
> On Tue, Oct 16, 2012 at 1:57 PM, David Cole  wrote:
>>
>> I have amended the commit and pushed this branch to the stage. If
>> anybody else would like to try it out they can grab the
>> "add-timestamp-subcommands" branch from the CMake stage repo.
>>
>> I did not merge it to 'next' yet, but I will do that when we're ready
>> to get it tested on the dashboards.
>>
>> Thanks for your work on this Nils.
>>
>>
>> David
>>
>>
>> On Tue, Oct 16, 2012 at 11:48 AM, Nils Gladitz  wrote:
>> > Ah that might explain it ... I may have been using nmake on Windows and
>> > ninja on linux.
>> > Thanks!
>> >
>> > Nils
>> >
>> >
>> > On 10/16/2012 05:27 PM, David Cole wrote:
>> >>
>> >> On Tue, Oct 16, 2012 at 10:12 AM, Nils Gladitz 
>> >> wrote:
>> >>>
>> >>> I certainly wouldn't mind though I'm not sure what that means.
>> >>> Do the changes in "next" still potentially make it into 2.8.10?
>> >>>
>> >> Going into 'next' is how stuff gets tested on the dashboards, and then
>> >> later Brad and I merge things to 'master' when they're ready.
>> >>
>> >> After something is merged to 'master' it will be in the CMake release
>> >> that follows that.
>> >>
>> >>
>> >>> Brad mentioned this would be on the TODO list for after 2.8.10.
>> >>>
>> >> We can put it in 'next' to vet it and correct any dashboard issues
>> >> that show up (errors/warnings on other platforms, other platform test
>> >> failures) at any time. But it will probably not go into 'master' until
>> >> after 2.8.10.
>> >>
>> >> We don't typically add significant features or take "risky" changes
>> >> after we start doing release candidates.
>> >>
>> >>
>> >>> I've tried to run all tests successfully before submitting but I can't
>> >>> tell
>> >>> if any of those were called "BootstrapTest".
>> >>> Is there anything special required to run it?
>> >>>
>> >> The BootstrapTest test only runs on "Unix Makefiles" based builds, so
>> >> if you're using a different generator, it does not get added as a
>> >> test.
>> >>
>> >>
>> >>> Nils
>> >>>
>> >>>
>> >>> On 10/16/2012 02:49 PM, David Cole wrote:
>> 
>>  I had to do this to get the bootstrap version of CMake to work (and
>>  the BootstrapTest to pass):
>> 
>>  $ git diff
>>  diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
>>  index 9d46355..8bf6c40 100644
>>  --- a/Source/CMakeLists.txt
>>  +++ b/Source/CMakeLists.txt
>>  @@ -264,8 +264,6 @@ set(SRCS
>>   cmTarget.cxx
>>   cmTarget.h
>>   cmTargetExport.h
>>  -  cmTimestamp.h
>>  -  cmTimestamp.cxx
>>   cmTest.cxx
>>   cmTest.h
>>   cmTestGenerator.cxx
>>  diff --git a/Source/cmBootstrapCommands.cxx
>>  b/Source/cmBootstrapCommands.cxx
>>  index 9097a74..e3a2ad4 100644
>>  --- a/Source/cmBootstrapCommands.cxx
>>  +++ b/Source/cmBootstrapCommands.cxx
>>  @@ -89,6 +89,7 @@
>> #include "cmStringCommand.cxx"
>> #include "cmSubdirCommand.cxx"
>> #include "cmTargetLinkLibrariesCommand.cxx"
>>  +#include "cmTimestamp.cxx"
>> #include "cmTryCompileCommand.cxx"
>> #include "cmTryRunCommand.cxx"
>> #include "cmUnsetCommand.cxx"
>> 
>> 
>>  After amending this, I'll push to next later today unless
>>  somebody
>>  objects to this??
>> 
>>  Thanks,
>>  David
>> 
>> 
>> 
>>  On Fri, Oct 5, 2012 at 4:16 PM, Nils Gladitz 
>>  wrote:
>> >
>> > I've updated the patch (attached) to return empty string on failure.
>> > I also tried to use the time definitions from global namespace
>> > rather
>> > than
>> > std::.
>> >
>> > Nils
>> >
>> >
>> > On 10/05/2012 09:17 PM, Brad King wrote:
>> >>
>> >> On 10/05/2012 02:53 PM, Nils Gladitz wrote:
>> >>>
>> >>> My initial thought was that "NOTFOUND" would be a good idea since
>> >>> it
>> >>> evaluates to false and the get_*_property commands also seem to
>> >>> use
>> >>> it.
>> >>
>> >> I wrote the more general "get_property" command to replace those
>> >> and
>> >> the newer command uses empty string rather than NOTFOUND.  It is
>> >> more
>> >> useful when computing pieces of a string to put together, perhaps
>> >> when
>> >> appending to a property value.
>> >>
>> >>> Looking at the documentation for "if()" again onl

Re: [cmake-developers] patch for cmake that adds a new timestamp command

2012-11-02 Thread Nils Gladitz 

Thanks!

Let me know if there is anything else I can do.

Nils

On 10/31/2012 09:52 PM, David Cole wrote:
Has anybody tried this anywhere else? I'm going to merge it to 'next' 
tomorrow, so that it will get tested on the dashboards after that. 
Just curious if there are any other known problems with it that I 
should squash in before doing that...


Thanks,
David



On Tue, Oct 16, 2012 at 1:57 PM, David Cole > wrote:


I have amended the commit and pushed this branch to the stage. If
anybody else would like to try it out they can grab the
"add-timestamp-subcommands" branch from the CMake stage repo.

I did not merge it to 'next' yet, but I will do that when we're ready
to get it tested on the dashboards.

Thanks for your work on this Nils.


David


On Tue, Oct 16, 2012 at 11:48 AM, Nils Gladitz mailto:glad...@sci-vis.de>> wrote:
> Ah that might explain it ... I may have been using nmake on
Windows and
> ninja on linux.
> Thanks!
>
> Nils
>
>
> On 10/16/2012 05:27 PM, David Cole wrote:
>>
>> On Tue, Oct 16, 2012 at 10:12 AM, Nils Gladitz
mailto:glad...@sci-vis.de>> wrote:
>>>
>>> I certainly wouldn't mind though I'm not sure what that means.
>>> Do the changes in "next" still potentially make it into 2.8.10?
>>>
>> Going into 'next' is how stuff gets tested on the dashboards,
and then
>> later Brad and I merge things to 'master' when they're ready.
>>
>> After something is merged to 'master' it will be in the CMake
release
>> that follows that.
>>
>>
>>> Brad mentioned this would be on the TODO list for after 2.8.10.
>>>
>> We can put it in 'next' to vet it and correct any dashboard issues
>> that show up (errors/warnings on other platforms, other
platform test
>> failures) at any time. But it will probably not go into
'master' until
>> after 2.8.10.
>>
>> We don't typically add significant features or take "risky" changes
>> after we start doing release candidates.
>>
>>
>>> I've tried to run all tests successfully before submitting but
I can't
>>> tell
>>> if any of those were called "BootstrapTest".
>>> Is there anything special required to run it?
>>>
>> The BootstrapTest test only runs on "Unix Makefiles" based
builds, so
>> if you're using a different generator, it does not get added as a
>> test.
>>
>>
>>> Nils
>>>
>>>
>>> On 10/16/2012 02:49 PM, David Cole wrote:

 I had to do this to get the bootstrap version of CMake to
work (and
 the BootstrapTest to pass):

 $ git diff
 diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
 index 9d46355..8bf6c40 100644
 --- a/Source/CMakeLists.txt
 +++ b/Source/CMakeLists.txt
 @@ -264,8 +264,6 @@ set(SRCS
  cmTarget.cxx
  cmTarget.h
  cmTargetExport.h
 -  cmTimestamp.h
 -  cmTimestamp.cxx
  cmTest.cxx
  cmTest.h
  cmTestGenerator.cxx
 diff --git a/Source/cmBootstrapCommands.cxx
 b/Source/cmBootstrapCommands.cxx
 index 9097a74..e3a2ad4 100644
 --- a/Source/cmBootstrapCommands.cxx
 +++ b/Source/cmBootstrapCommands.cxx
 @@ -89,6 +89,7 @@
#include "cmStringCommand.cxx"
#include "cmSubdirCommand.cxx"
#include "cmTargetLinkLibrariesCommand.cxx"
 +#include "cmTimestamp.cxx"
#include "cmTryCompileCommand.cxx"
#include "cmTryRunCommand.cxx"
#include "cmUnsetCommand.cxx"


 After amending this, I'll push to next later today unless
somebody
 objects to this??

 Thanks,
 David



 On Fri, Oct 5, 2012 at 4:16 PM, Nils Gladitz
mailto:glad...@sci-vis.de>> wrote:
>
> I've updated the patch (attached) to return empty string on
failure.
> I also tried to use the time definitions from global
namespace rather
> than
> std::.
>
> Nils
>
>
> On 10/05/2012 09:17 PM, Brad King wrote:
>>
>> On 10/05/2012 02:53 PM, Nils Gladitz wrote:
>>>
>>> My initial thought was that "NOTFOUND" would be a good
idea since it
>>> evaluates to false and the get_*_property commands also
seem to use
>>> it.
>>
>> I wrote the more general "get_property" command to replace
those and
>> the newer command uses empty string rather than NOTFOUND.
 It is more
>> useful when computing pieces of a string to put together,
perhaps when
>> appending to a property value.
>>
>>> Looking at the documentation for "if()" again only
"-NO

Re: [cmake-developers] Testing Config generator expression

2012-11-02 Thread Stephen Kelly 
Brad King wrote:

> On 11/02/2012 05:26 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> I think just this will be sufficient (untested):
>> 
>> I wasn't able to make that work. Also any solution based on using script
>> mode didn't work because I can't use add_custom_command there.
> 
> It isn't script mode.  The patch below works for me.

I've merged it to next.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Testing Config generator expression

2012-11-02 Thread Brad King 
On 11/02/2012 05:26 AM, Stephen Kelly wrote:
> Brad King wrote:
>> I think just this will be sufficient (untested):
> 
> I wasn't able to make that work. Also any solution based on using script 
> mode didn't work because I can't use add_custom_command there. 

It isn't script mode.  The patch below works for me.

-Brad


diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 077bbc4..c937906 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -556,6 +556,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P 
${CMake_SOURCE_DIR}/Utilities/
 --build-generator ${CMAKE_TEST_GENERATOR}
 --build-project GeneratorExpression
 --build-makeprogram ${CMAKE_TEST_MAKEPROGRAM}
+--build-options -DCMAKE_BUILD_TYPE=\${CTEST_CONFIGURATION_TYPE}
 )
   list(APPEND TEST_BUILD_DIRS "${CMake_BINARY_DIR}/Tests/GeneratorExpression")

diff --git a/Tests/GeneratorExpression/CMakeLists.txt 
b/Tests/GeneratorExpression/CMakeLists.txt
index 581d483..3a92d81 100644
--- a/Tests/GeneratorExpression/CMakeLists.txt
+++ b/Tests/GeneratorExpression/CMakeLists.txt
@@ -19,6 +19,10 @@ add_custom_target(check ALL
 -Dtest_and_0_invalidcontent=$
 -Dtest_config_0=$x>
 -Dtest_config_1=$>
+-Dtest_config_debug=$$$
+-Dtest_config_release=$$$
+
-Dtest_config_relwithdebinfo=$$$
+
-Dtest_config_minsizerel=$$$
 -Dtest_not_0=$
 -Dtest_not_1=$
 -Dtest_or_0=$
diff --git a/Tests/GeneratorExpression/check.cmake 
b/Tests/GeneratorExpression/check.cmake
index 88a60ce..af436de 100644
--- a/Tests/GeneratorExpression/check.cmake
+++ b/Tests/GeneratorExpression/check.cmake
@@ -18,6 +18,11 @@ check(test_and_1_1 "1")
 check(test_and_0_invalidcontent "0")
 check(test_config_0 "0")
 check(test_config_1 "1")
+foreach(c debug release relwithdebinfo minsizerel)
+  if(NOT "${test_config_${c}}" MATCHES "^(0+|1+)$")
+message(SEND_ERROR "test_config_${c} is \"${test_config_${c}}\", not all 0 
or all 1")
+  endif()
+endforeach()
 check(test_not_0 "1")
 check(test_not_1 "0")
 check(test_or_0 "0")
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013643]: GenerateExportHeader should work for module libraries too

2012-11-02 Thread Mantis Bug Tracker 

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=13643 
== 
Reported By:Gregoire
Assigned To:
== 
Project:CMake
Issue ID:   13643
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-11-02 06:13 EDT
Last Modified:  2012-11-02 06:13 EDT
== 
Summary:GenerateExportHeader should work for module
libraries too
Description: 
I am doing my tests with visual 2008 and mingw.

As far as I understand a module is like a shared library that cannot 
be linked. Instead it is dynamically loaded and then we find and use 
symbols in it. It is like doing the linker's job manually at runtime.
 
If nothing is exported from my module then I do cannot find any 
symbol in it. Or at least I do not know how to do so.
 
I modified the GenerateExportHeader module to be able to export 
symbols from my MODULE:

# if(${type} STREQUAL "MODULE")
   # message(WARNING "This macro should not be used with libraries of
   # type MODULE") return()
# endif()
if(NOT ${type} STREQUAL "STATIC_LIBRARY" AND NOT ${type} STREQUAL
"SHARED_LIBRARY" AND NOT ${type} STREQUAL "MODULE_LIBRARY")
   message(WARNING "This macro can only be used with libraries")
   return()
endif()


Steps to Reproduce: 
Build a module with visual without exported symbols.
Use depends.exe (from http://www.dependencywalker.com/) to open the generated
dll.
It will not find any symbols which means that your application won't be able to
find it either, the module is useless.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-11-02 06:13 Gregoire   New Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Testing Config generator expression

2012-11-02 Thread Stephen Kelly 
Brad King wrote:

> On 11/01/2012 11:45 AM, Stephen Kelly wrote:
>> Ok, I've added a test for that, but as that test uses CMAKE_COMMAND too,
>> with makefile generators, the result will be  each time.
> 
> Okay, now I see what you meant before.  Sorry.
> 
> I think just this will be sufficient (untested):
> 

I wasn't able to make that work. Also any solution based on using script 
mode didn't work because I can't use add_custom_command there. 

I've added a solution based on creating top-level tests. Please let me know 
if I should merge that to next.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers