[cmake-developers] [CMake 0014352]: CMake crashing with white space in generator expression

2013-08-13 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14352 
== 
Reported By:chrislu
Assigned To:
== 
Project:CMake
Issue ID:   14352
Category:   CCMake
Reproducibility:always
Severity:   crash
Priority:   high
Status: new
== 
Date Submitted: 2013-08-13 04:01 EDT
Last Modified:  2013-08-13 04:01 EDT
== 
Summary:CMake crashing with white space in generator
expression
Description: 
With the blow custom command the cmake gui is crashing with the white space
behind the : after the ARGS command. Removing the space fixes this.

add_custom_command(OUTPUT   ${CUDA_NVCC_OUTPUT_FILE}
   COMMAND  ${SCM_CUDA_NVCC_COMMAND}
   ARGS $$CONFIG:Debug:
${SCM_CUDA_NVCC_OPTIONS_DEBUG}
${SCM_CUDA_NVCC_OPTIONS} 
${SCM_CUDA_NVCC_INC_DIR_STRING}
${SCM_CUDA_NVCC_DEF_STRING}
-o \${CUDA_NVCC_OUTPUT_FILE}\
\${input_file}\
   MAIN_DEPENDENCY ${input_file}
   DEPENDS  ${input_file}
   COMMENT NVCC compiling (${input_file_name}):)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-08-13 04:01 chrisluNew 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 0014353]: generator expression $1:... and $0:... fail with white space in provided strings.

2013-08-13 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14353 
== 
Reported By:chrislu
Assigned To:
== 
Project:CMake
Issue ID:   14353
Category:   CCMake
Reproducibility:always
Severity:   block
Priority:   urgent
Status: new
== 
Date Submitted: 2013-08-13 04:12 EDT
Last Modified:  2013-08-13 04:12 EDT
== 
Summary:generator expression $1:... and $0:... fail with
white space in provided strings.
Description: 
the below example breaks when spaces are in the argument lists.

for the release configuration everything works as expected as the argument list
contains just a single entry. but for the debug configuration $1:something
something dark side is inserted into the argument list.

this is very urgend as CMake does offer no other way to set different arguments
to the custom commands depending on the configuration!

set(SCM_ARGS_A something)
set(SCM_ARGS_B something something dark side)

add_custom_command(OUTPUT   ${CUDA_NVCC_OUTPUT_FILE}
   COMMAND  ${SCM_CUDA_NVCC_COMMAND}
   ARGS $$CONFIG:Release:${SCM_ARGS_A}
$$CONFIG:Debug:${SCM_ARGS_B }
${SCM_CUDA_NVCC_OPTIONS} 
${SCM_CUDA_NVCC_INC_DIR_STRING}
${SCM_CUDA_NVCC_DEF_STRING}
-o \${CUDA_NVCC_OUTPUT_FILE}\
\${input_file}\
   MAIN_DEPENDENCY ${input_file}
   DEPENDS  ${input_file}
   COMMENT NVCC compiling (${input_file_name}):)
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-08-13 04:12 chrisluNew 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] Please review CXXFeatures.cmake

2013-08-13 Thread Stephen Kelly
Stephen Kelly wrote:
 I still think you should revisit my review mail on point 2 too.

Something that becomes possible when thinking about the above and target 
properties is interface requirements. 

If my library uses 'final' unguarded by macros in my headers, then I want to 
communicate through the target that a compiler supporting that feature is 
required.

 set_property(TARGET foo PROPERTY INTERFACE_CXX_COMPILER_FEATURE_final 1)

which would work similiarly to (and using the same infrastructure as) 
INTERFACE_POSITION_INDEPENDENT_CODE.

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] Please review CXXFeatures.cmake

2013-08-13 Thread Brad King
On 08/02/2013 05:20 PM, Rolf Eike Beer wrote:
 Brad, please don't merge that

Do all of the remaining test failures need the cxx-flags topic to fix?

 
http://open.cdash.org/testSummary.php?project=1name=Module.FindCXXFeaturesdate=2013-08-13

I'd like to get these resolved or revert the topic because the noise
on the dashboard is very distracting while trying to get 2.8.12-rc1 out.

On Win64-vs10-Tv90 it is building with VS 10 but the compiler is VS 9.
The logic that sets MSVC_VERSION should be correct in this case so I'm
not sure what is causing the expected results to mismatch.

For Win32-mingw-gcc-4.5 and Win32-msys-gcc-4.5, does the MinGW port of
the compiler support all the same features?  It is GNU 4.5.0.

For the Linux*-LSB4.0 builds with GNU 4.3.2:

 CMake Error at CMakeLists.txt:203 (message):
   C++ feature 'CXXFeatures_cstdint_header_FOUND' was detected, but not
   expected

the LSB-enforcing compilers may provide that header.

For MacOSX10.7-Xcode43-ub, it is the Apple port of the GNU 4.2.1 so
there are more features than expected.

For Windows-icl-11.1-*, why do the expected results not just match
for this version?

Also, IMO if (CMAKE_COMPILER_IS_GNUCXX) and elseif (MSVC) should
use CMAKE_CXX_COMPILER_ID instead just like the rest of the cases.

Thanks,
-Brad
--

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] Please review CXXFeatures.cmake

2013-08-13 Thread Rolf Eike Beer
Brad King wrote:
 On 08/02/2013 05:20 PM, Rolf Eike Beer wrote:
  Brad, please don't merge that
 
 Do all of the remaining test failures need the cxx-flags topic to fix?

No, since both are in next already everything that still shows up as a bug is 
a bug.

  http://open.cdash.org/testSummary.php?project=1name=Module.FindCXXFeatures
 date=2013-08-13
 
 I'd like to get these resolved or revert the topic because the noise
 on the dashboard is very distracting while trying to get 2.8.12-rc1 out.

I'm working on it.

 On Win64-vs10-Tv90 it is building with VS 10 but the compiler is VS 9.
 The logic that sets MSVC_VERSION should be correct in this case so I'm
 not sure what is causing the expected results to mismatch.

The expected features seen here indicate that MSVC_VERSION is 1600 (i.e. 
VC10). Which is correct IMHO, as it gives the version of the suite, not the 
compiler. I'll switch that over to use CMAKE_CXX_COMPILER_VERSION as suggested 
below, the error will probably go away then.

 For Win32-mingw-gcc-4.5   and Win32-msys-gcc-4.5, does the MinGW port of
 the compiler support all the same features?  It is GNU 4.5.0.

I would have expected it so.

 For the Linux*-LSB4.0 builds with GNU 4.3.2:
 
  CMake Error at CMakeLists.txt:203 (message):
C++ feature 'CXXFeatures_cstdint_header_FOUND' was detected, but not
expected
 
 the LSB-enforcing compilers may provide that header.

 For MacOSX10.7-Xcode43-ub, it is the Apple port of the GNU 4.2.1 so
 there are more features than expected.

Because of the Clang version mixup already discussed I plan to make the more 
features found than expected message a WARNING instead of an error. I can do 
this now and sort the other expected features out next week or so when you 
have the RC ready. This is only part of how we verify that the module works, 
not the module itself.

 For Windows-icl-11.1-*, why do the expected results not just match
 for this version?

That is a question I wanted to bring up, too. Can you log into that machine 
and get me the intermediate results of the try_compile calls?

 Also, IMO if (CMAKE_COMPILER_IS_GNUCXX) and elseif (MSVC) should
 use CMAKE_CXX_COMPILER_ID instead just like the rest of the cases.

Agreed, as above.

Eike
-- 

signature.asc
Description: This is a digitally signed message part.
--

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 0014355]: Implementation of qt4_add_executable/library

2013-08-13 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14355 
== 
Reported By:Daniel Schepler
Assigned To:
== 
Project:CMake
Issue ID:   14355
Category:   Modules
Reproducibility:N/A
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2013-08-13 15:57 EDT
Last Modified:  2013-08-13 15:57 EDT
== 
Summary:Implementation of qt4_add_executable/library
Description: 
Here's a set of Qt4 utility macros I developed for a project here.  Got
permission from my supervisor to submit it here in case you'd be interested in
adding it (they could potentially be useful for any project using Qt4).  It
would be suitable either as a separate addon, or as additional content to be
incorporated into Qt4Macros.cmake.

The first macro, qt4_source_groups(), should be self-explanatory.  The rest is
mainly meant as support for the main macros, qt4_add_executable() and
qt4_add_library(), which automate the process of calling qt4_wrap_cpp(),
qt4_add_resources(), etc.

Some potential issues: It currently only handles .ui, .qrc files and headers
which need MOC generation; it doesn't handle other things like DBus interface
files, though those shouldn't be too hard to add if somebody needs them.  And it
doesn't handle automoc, as I have no idea how that's supposed to work.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-08-13 15:57 Daniel ScheplerNew Issue
2013-08-13 15:57 Daniel ScheplerFile Added: QtUtilMacros.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] CDash [CMake] - Nightly Expected Failures

2013-08-13 Thread Rolf Eike Beer
 *Dynamic analysis tests failing or not run*
 CTestTestMemcheckDummyPurify
 (http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977143)
 CTestTestMemcheckDummyValgrind
 (http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977144)
 CTestTestMemcheckDummyValgrindIgnoreMemcheck
 (http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977146)
 CTestTestMemcheckDummyValgrindPrePost
 (http://open.cdash.org/viewDynamicAnalysisFile.php?id=2977145)

Can someone explain those to me? I don't understand what's going wrong there.

Thx

Eike
-- 

signature.asc
Description: This is a digitally signed message part.
--

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