MantisBT - Issues

0012933: #Ifdef from cmake having no effect on preprocesser blocks

Fri, 03 Feb 2012 16:20:11 -0500

After recent changes many definitions for using modules added through cmake are not passed along.

The changes to the CMakesLists appear to be the cause.

Trace Edit is an Example as neither USE_Clusclus or USE_SPD are defined.

0012929: The "-shared" gcc option is not provided for MODULE shared library CXX is enabled before C

Fri, 03 Feb 2012 15:51:50 -0500

The "-shared" gcc option is not provided for MODULE shared library, if PROJECT command declares in some ways.

test cases:
PROJECT (${proj_name}) - OK
PROJECT (${proj_name}C CXX) - OK
without PROJECT command - OK
PROJECT (${proj_name}CXX) - FAIL
PROJECT (${proj_name}CXX C) - FAIL

CMAKE_SHARED_MODULE_CREATE_C_FLAGS gets its initial value in CMakeCInformation.cmake from CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS.

It seems that if CMakeCXXInformation.cmake is called before CMakeCInformation.cmake, The variable CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS will take the default value of CMAKE_SHARED_MODULE_CREATE_C_FLAGS which is blank at that moment.

As shown in CMakeCXXInformation.cmake files:
161 # repeat for modules
162 IF(NOT CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS)
163 SET(CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS ${CMAKE_SHARED_MODULE_CREATE_C_FLAGS})
164 ENDIF(NOT CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS)

The "-shared" gcc option is provided for SHARED library in any case.

Since CMakeGenericSystem.cmake gives CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS default value "-shared". And in CMakeCXXInformation.cmake, '-shared' is passed to CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS.

0012932: gccxml lacks support for gcc 4.7

Fri, 03 Feb 2012 14:48:58 -0500

Fedora 17 uses gcc 4.7. gccxml has no support for it

0012930: [patch] CMake does not support Visual Studio 11 WinRT project type

Fri, 03 Feb 2012 14:46:40 -0500

CMake currently does not support setting project type as needed to develop WinRT applications for Windows 8 with the Visual Studio 10 generator.

Patch is based on a similar patch for .NET project types from here: http://public.kitware.com/Bug/view.php?id=12586 [^]

0012632: Visual studio 2011 compiler support

Fri, 03 Feb 2012 12:11:24 -0500

Visual studio 2011 compiler not supported and compilation fails.

0011463: msvc10 support.

Fri, 03 Feb 2012 12:10:30 -0500

I'd really like to see msvc10 support in gccxml soon. I started the necessary integration in vcInstall.cxx and gxConfiguration.cxx but i guess the main work lies in supplying the .patch files for the headers and it appears to be to much work for me right now. And i must admit that having houndred of compile errors thrown at one is not that encouraging if you get stuck for hours in the first one ;)

What i've observed so far:

apperently the registry key for the vc-installation has moved - or my installation is broken (tryed to repair - but guess what...).

so instead of:
"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\10.0\\Setup\\VC;ProductDir"
i used:
"HKEY_CURRENT_USER\\Software\\Microsoft\\VisualStudio\\10.0_Config\\Setup\\VS;ProductDir"

after my changes gccxml and gccxml_vccconfig appear to be working correctly. I tried to use the patches for msvc9 but this did not work out. Got lots of errors during the patching.

Any suggestions on the process to stitch up the patches would be welcome.

regards
-- Benjamin Schulz

PS.: sorry for supplying raw files instead of patches.

0012931: MSVC 2010 project generation filters out known compile flags

Fri, 03 Feb 2012 10:54:34 -0500

I'm trying to have a library with only one file compiled with clr support.
The Makefile generator adds my flags correctly.

But the visual studio 10 generator filters out the known flags (/clr /FU...)

0011719: FindCUDA should look for libcuda in /usr/lib{,64}/nvidia

Fri, 03 Feb 2012 09:06:44 -0500

The rpmfusion nvidia driver packages install libcuda.so in /usr/lib{,64}/nvidia. I think FindCUDA should add that to the search path.

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 1547b19..e3c7533 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -567,7 +567,7 @@ endif()

# 1.1 toolkit on linux doesn't appear to have a separate library on
# some platforms.
-find_library_local_first(CUDA_CUDA_LIBRARY cuda "\"cuda\" library (older versions only).")
+find_library_local_first(CUDA_CUDA_LIBRARY cuda PATH_SUFFIXES nvdia DOC "\"cuda\" library (older

# Add cuda library to the link line only if it is found.
if (CUDA_CUDA_LIBRARY)

0012586: [patch] CMake does not support Visual Studio projects types or dotnet references with managed C++

Fri, 03 Feb 2012 09:04:15 -0500

CMake currently does not support setting project types or .NET references on managed C++ projects with the Visual Studio 10 generator.

This is not a very "cross-platform" feature (unless Mono supports managed C++?) but it is necessary for unit testing projects in Visual Studio.

0012928: CMake silently ignores CPPFLAGS

Fri, 03 Feb 2012 08:53:36 -0500

CMake silently ignores CPPFLAGS, which should be accepted from environmental variables.

0012927: User view option per project

Thu, 02 Feb 2012 14:25:00 -0500

It would be nice to add a new tab when subscribing to a project to display what we want to see (mainly the notes icon for a given build).

0012881: \DYNAMICBASE and \NXCOMPAT don't work on Visual Studio 8 2005 builds

Thu, 02 Feb 2012 14:05:23 -0500

Creating vcproj file for Visual Studio 8 2005. When adding linker flags \DYNAMICBASE and \NXCOMPAT

For instance by having this in the CMakeLists.txt file:
set(CMAKE_SHARED_LINKER_FLAGS_DEBUG "${CMAKE_EXE_LINKER_FLAGS_DEBUG} /NXCOMPAT /DYNAMICBASE")

CMake is translating this to, DataExecutionPrevention="2" and RandomizedBaseAddress="2" something that Visual Studio 8 2005 don't understand and being ignored by the linker.

If I manually add \DYNAMICBASE and \NXCOMPAT to the AdditionalOptions parameter it works fine.

0006929: Intel C++ project generation

Thu, 02 Feb 2012 13:31:48 -0500

It would be great if cmake could directly generate Intel C++ project files (.icproj) for Microsoft Visual Studio 2005.

Intel project files can be generated from within VS2005 from the ".vcproj"s.
Direct support would remove the need to regenerate the ".icproj"s manually every time cmake updates the ".vcproj"s.

brad.king also suggested that this would solve issues with boost detection due to unset compiler id. (Issue 0006926)

0012926: FindPkgConfig module doesn't honor CMAKE_PREFIX_PATH.

Thu, 02 Feb 2012 10:29:02 -0500

There is a environment variable PKG_CONFIG_PATH, which makes pkg-config to look for .pc's there first. For now, the only way to pass this variable to the FindPkgConfig i've found is to run cmake executable with this env var set. Wouldn't it be more consistent and neat to make FindPkgConfig to look at CMAKE_PREFIX_PATH?

0010531: Install-rules for individual components

Thu, 02 Feb 2012 08:17:14 -0500

Installing individual components is currently non-intuitive and tedious. People expect to be able to simply type:

make install-man
make install-bin
make install-shlibs

or similar.

0002582: Set XCode arguments from CMakeLists.txt

Thu, 02 Feb 2012 08:03:16 -0500

Is there a way to set the XCode internal variables from CMake? As a specific example, I have an application that uses the DYLD_LIBRARY_PATH to find shared libraries during development. XCode requires that the environment variable be set internally on the executable so that the executable can be run/debugged. I can set it within XCode but it gets lost everytime I rebuild the project with CMake. Is there anyway to set the DYLD_LIBRARY_PATH from my CMakeLists.txt?

0012555: Asynchronous processing of submission fails with drop site of the form: slicer4.cdash.org

Thu, 02 Feb 2012 07:21:41 -0500

Note that in both of the cases described below, the submission and the queuing of processing jobs are properly done.

In case 1), the queued job are also processed as expected.

Nevertheless, in case 2) the jobs seems not to be processed.

Case 1:

set(CTEST_DROP_METHOD "http")
set(CTEST_DROP_SITE "www.cdash.org/slicer4")
set(CTEST_DROP_LOCATION "/submit.php?project=Slicer4")
set(CTEST_DROP_SITE_CDASH TRUE)

Case 2:

set(CTEST_DROP_METHOD "http")
set(CTEST_DROP_SITE "slicer.cdash.org")
set(CTEST_DROP_LOCATION "/submit.php?project=Slicer4")
set(CTEST_DROP_SITE_CDASH TRUE)

Seems that the code setting currentUri line 211 of do_submit.php is not handling both case adequately.

0006493: configuration dependent COMPILE_FLAGS for SET_TARGET_PROPERTIES

Thu, 02 Feb 2012 07:05:55 -0500

There already are configuration dependent LINK_FLAGS like LINK_FLAGS_DEBUG, LINK_FLAGS_RELEASE. This could be usefule for COMPILE_FLAGS too.

0011809: "My Build Schedules" might benefit from an extra Comments or Description column

Thu, 02 Feb 2012 06:49:41 -0500

Preferably a free text field that could be edited in the "Schedule a build" form.

0008884: Set Visual Studio project "custom environment variables" setting with CMake

Wed, 01 Feb 2012 23:22:54 -0500

Feature Request

In Visual Studio, you can add custom environment variables that will
exist if you run your application from visual studio. They are at
[executable project]-->Properties-->Configuration
Properties-->Debugging-->Environment

Setting these is especially useful to add the correct (Debug/Release) include paths to your project.

Example:
My project needs to have a debug version of ITKCommon.dll in its PATH
when running in Debug mode and a Release version of the DLL in Release
mode respectively. Otherwise it will crash with a

Manually setting the project environment setting to
"PATH=%ITK_DIR%\bin\$(OutType);%PATH%" allows me to automatically use
the correct path, as is suggested in the VTK FAQ
(<http://vtkedge.org/Wiki/VTK_FAQ#Shared_builds_of_VTK_and_debugging_QVT [^]
KWidget_using_Visual_Studio>). But the next CMake run will overwrite this setting. Therefore, a posibility to set this with CMake would be really useful. Other use cases exist too. For example, it can be used to set other environment variables as well, that could be read by the application.

0012129: Add top level directory to component install

Wed, 01 Feb 2012 17:42:49 -0500

When CPACK_ARCHIVE_COMPONENT_INSTALL is on, the packages do not contain a top level directory, unlike with the non component install. This is true even if CPACK_INCLUDE_TOPLEVEL_DIRECTORY is enabled.

It would be nice if a top level directory could be added. This would mirror the behavior of the non component install and prevent an annoying surprise for anyone untarring without listing the contents first.

I also think having this top level directory should be the default, since CPACK_INCLUDE_TOPLEVEL_DIRECTORY=1 is the default for archives.

0012919: Wrong include path passed to nasm

Wed, 01 Feb 2012 12:13:04 -0500

When ASM files are using %include, current CMake configuration for nasm is wrong and we got "Unable to open include file ...".

That's because nasm seems to need a trailing slash/backslash in path after a -I

0012923: NSIS installer doesn't honor user permission

Wed, 01 Feb 2012 08:23:45 -0500

When using the NSIS generator from CPack the file NSIS.template.in is used to generate a project.nsi file for NSIS to process. The file consists code in the NSIS scripting language. Among other functions there is an onInit function the initializes the installer. The function (tries to) recognise admin and power users but fails since NSIS scripting language relative includes the jump from the current command so +3 means "run the third command after this one", so a failed check for admin completely skips the check for a power user and goes directly to "done:"

0012918: CMake wrongly generates x64 VC10 project files when Boost default stage folder is used for x32

Wed, 01 Feb 2012 08:00:02 -0500

I've got two builds of boost libraries for x32 and x64, being staged into \stage and \vc10x64_stage respectively.

with this command for the attached CMakeLists.txt below:
cmake ../.. -G"Visual Studio 10 Win64"
it correctly find the \vc10x64_stage folder, e.g.:

-- Check for working C compiler using: Visual Studio 10 Win64
-- Check for working C compiler using: Visual Studio 10 Win64 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 10 Win64
-- Check for working CXX compiler using: Visual Studio 10 Win64 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Using 64bit compiler
-- Using 64bit Boost libs at X:/ttan/open-source/boost/trunk/vc10x64_stage/lib for host&machine exes
-- Boost version: 1.49.0
-- Found the following Boost libraries:
-- system
-- date_time
-- thread
-- Using 64bit Boost libs at X:/ttan/open-source/boost/trunk/vc10x64_stage/lib for test executables
-- Using 64bit Boost libs at X:/ttan/open-source/boost/trunk/vc10x64_stage/lib for pyhostlink lib
-- Boost version: 1.49.0
-- Found the following Boost libraries:
-- system
-- date_time
-- thread
-- python
-- Found PythonLibs: C:/Python27/libs/python27.lib
-- Configuring done
-- Generating done
-- Build files have been written to: D:/H/src/build

but fails to write into element in the .vcxproj files, which actually refer to the libs under /stage.

Renaming /stage to something else solves the problem

0012925: FindBLAS.cmake and FindLAPACK.cmake Do Not Find Sequential MKL 10.3

Wed, 01 Feb 2012 03:14:59 -0500

Intel MKL version 10.3 ships with a sequential version. FindBLAS and FindLAPACK only have support for the parallel versions, however. A fix seems as easy as adding an extra BLA_VENDOR for the the sequential version of MKL.