MantisBT - Issues

0012644: Modules/Qt4Macros.cmake: qt4_create_translation: missing include paths

Wed, 08 Feb 2012 21:02:38 -0500

The macro does not give lupdate the include paths given in the makefile, therefore lupdate produces warnings like "Qualifying with unknown namespace/class ::Foo" and possibly bad files. lupdate needs the class definition to not throw these warnings.

0012900: Sequence of pathes for Qt

Wed, 08 Feb 2012 20:50:13 -0500

First of all Path to Qt searches in register which brings some problerms with sevral Qt verstion. I think, that it will be very good if first of all Qt path searches in QTDIR and only then in register and others

0012915: Bad wording in FindQt4.cmake

Wed, 08 Feb 2012 20:42:46 -0500

In Modules/FindQt4.cmake, one can read:

"Warning: But QtCore couldn't be found. Qt must NOT be installed correctly, or it wasn't found for cross compiling."

Really, Qt must NOT be installed correctly?! :-)
That wording is simply wrong. I propose "Qt is NOT installed correctly."

I attached the Git patch.

0012414: Mistakes in FindQt3.cmake and FindQt4.cmake Qt version definition

Wed, 08 Feb 2012 20:27:01 -0500

Files FindQt3.cmake and FindQt4.cmake have mistakes in defining required Qt version for building program. Minor version variable recieves only the first digit but not two or more.

0012947: ctest_coverage not submitting coverage with superbuild setups.

Wed, 08 Feb 2012 19:27:42 -0500

See

http://www.cdash.org/CDash/viewNotes.php?buildid=1989226 [^]

The "file( APPEND ${CTEST_BINARY_DIRECTORY}/CMakeFiles/TargetDirectories.txt" ... is required to get processing of the coverage for this superbuild project. Otherwise, the ctest_coverage command results in a message that Coverage.xml is not found, and the coverage submission does not occur.

Also, it is not intuitive that the path sent to "ctest_coverage( BUILD" is ${CTEST_BINARY_DIRECTORY} instead of ${CTEST_BINARY_DIRECTORY}/Farsight in this case. That is, I would expect that the build directory for the project instead of the build directory for the superbuild should be passed to "ctest_coverage( BUILD" as is done with "ctest_build( BUILD". However, ${CTEST_BINARY_DIRECTORY}/Farsight is passed, it does not submit the correct coverage results.

0012935: When CPACK_INCLUDE_TOPLEVEL_DIRECTORY is set to 1, the NSIS generator is always failed to be initialized

Wed, 08 Feb 2012 18:43:51 -0500

When set CPACK_INCLUDE_TOPLEVEL_DIRECTORY to 1 in the CMakeLists.txt, "nmake package" or "wmake package" (not tried other compilers) will lead to the following output:

CPack Error: NSIS Generator cannot work with CPACK_INCLUDE_TOPLEVEL_DIRECTORY. This option will be ignored.
CPack Error: Cannot initialize the generator NSIS

As long as it says this option will be ignored, the error should not be caused.

I have NSIS installed on my machine. The original source tree could be found here:

https://github.com/editorconfig/editorconfig/zipball/90978de4e2bfcdf6577ceb54edba9a044f10c5ba [^]

0012338: FindPythonInterp.cmake searches for the newest python executable

Wed, 08 Feb 2012 14:37:57 -0500

The current FindPythonInterp.cmake file by default searches for the newest python version. Because it is possible to install different version of python and per default to use not the newest installed one this approach is often not correct.

0012425: 'pgfortran' should be in the list of supported PGI compilers

Wed, 08 Feb 2012 14:31:44 -0500

Modules/CMakeDetermineFortranCompiler.cmake should include 'pgfortran' as a Portland Group compiler.

The manual at http://www.pgroup.com/doc/pgiug.pdf [^] says that 'pgfortran' is equivalent to 'pgf95' and share the same flags.

0011785: CPack no stripping with MinGW and NSIS

Wed, 08 Feb 2012 14:21:14 -0500

When I install with "mingw32-make install/strip"
the installed files are stripped.

But when I set CPACK_STRIP_FILES to 1 and
use NSIS with "mingw32-make package" the binaries
are not stripped.

CPackConfig.cmake looks correct:

SET(CPACK_BINARY_NSIS "ON")
...
SET(CPACK_CMAKE_GENERATOR "MinGW Makefiles")
...
SET(CPACK_STRIP_FILES "1")

http://www.cmake.org/pipermail/cmake/2011-February/042436.html [^]

0012447: the Xmu library is not detected by cmake

Wed, 08 Feb 2012 14:18:41 -0500

The Xmu library is part of xorg.
It's required by one of my project, but FindX11.cmake doesn't detect it.
I must use FindGLUT.cmake to detect Xmu.

0012466: FindGLUT does not honor REQUIRED

Wed, 08 Feb 2012 14:06:05 -0500

With no glut installed cmake does not stop build phase in spite of REQUIRED.

0012626: FindJPEG/FindTIFF.cmake do not define _INCLUDE_DIRS variables

Wed, 08 Feb 2012 13:38:19 -0500

In the "How package finding works" section of the CMake wiki it is described that each library defines a "_INCLUDE_DIRS" variable. (cf. http://www.vtk.org/Wiki/CMake:How_To_Find_Libraries [^]) However, FindJPEG.cmake and FindTIFF.cmake seem not to do so.
This problem is analog to bug 0011312 related to the FindPNG.cmake.

In our currently checked out VTK-version from 2011-04-12 this leads to missing include paths when using Custom-Versions of these libraries.

0012946: Lack of ability to specify location of SSL CA bundle at compile time

Wed, 08 Feb 2012 13:23:53 -0500

Currently, there is no way of specifying location of SSL CA bundle at compile time. Source code has to be changed first. Addition of the following code to Utilities/cmcurl/CMakeLists.txt would fix the problem:

SET(CURL_CA_BUNDLE "" CACHE FILEPATH "Path to SSL CA Certificate Bundle")
MARK_AS_ADVANCED(CURL_CA_BUNDLE)
IF(CURL_CA_BUNDLE)
ADD_DEFINITIONS(-DCURL_CA_BUNDLE="${CURL_CA_BUNDLE}")
ENDIF(CURL_CA_BUNDLE)

0011910: FindOpenMP.cmake requires both C and CXX

Wed, 08 Feb 2012 13:04:03 -0500

If only CXX is enabled and not C, then many errors are produced that look like this (path shortened):

-- Performing Test OpenMP_FLAG_DETECTED
CMake Error: Unknown extension ".c" for file ".../build/CMakeFiles/CMakeTmp/src.c". TRY_COMPILE only works for enabled languages.
Currently enabled languages are: CXX
See PROJECT command for help enabling other languages.

Looking at the module, it seems that (1) it performs both the C and CXX tests unconditionally. So if C is not enabled, then the C tests will generate the above error. (2) Also, at the end of the module, the use of find_package_handle_standard_args() seems to require that both C and CXX flags have to be set.

Also, (3) there is a minor problem with the check_c_source_compiles () using the CXX source, and vice-versa. (As the two sources are identical, the effect is trivial.)

-----

Notes:
1) Debian 6.0 is using cmake 2.8.2 . However, looking at 2.8.4, it seems that the problem still persists.
2) A similar problem for an entirely different module appears to be described here: //www.mail-archive.com/cmake@cmake.org/msg06043.html">http://www.mail-archive.com/cmake@cmake.org/msg06043.html [//www.mail-archive.com/cmake@cmake.org/msg06043.html" target="_blank">^]]

0012942: Would like to specify a different default location for OSX binary

Wed, 08 Feb 2012 09:06:45 -0500

We don't put our apps in the default location. We have a change to cmTarget.cxx to make this happen.

We means I finally got permission to report changes my employer made to the code base.

0012945: CMake should support custom commands that can vary by configuration

Wed, 08 Feb 2012 09:00:22 -0500

I think I have a use-case for the feature requested in issue 9974.

Boost DLLs/SOs need to be copied in place to run tests. The have config-specific filenames, so the only way I can see to make it work is to copy all of them for all configs, which is not ideal. Boost_SHARED_LIBRARIES_RELEASE and Boost_SHARED_LIBRARIES_DEBUG below are constructed from the variables provided by the FindBoost module.

foreach(file ${Boost_SHARED_LIBRARIES_RELEASE} ${Boost_SHARED_LIBRARIES_DEBUG})
mb_message(STATUS "copying ${file} to binary dir")
add_custom_command(
TARGET SETUP_TESTS PRE_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${file} $)
endforeach()

0012944: Feature enabling the CheckC*.cmake macros to use a path to source code as well as supplied source code

Wed, 08 Feb 2012 08:36:46 -0500

We often have our own .c file stored in our tree for TRY_RUN testing,
and it is convenient to be able to use CHECK_C_RUNS_SOURCE for testing
those .c files. At the moment, CHECK_C_RUNS_SOURCE assumes the
incoming SOURCE variable actually holds the source code - our
enhancement checks to see if SOURCE holds a valid file path first. If
it DOES hold a valid file path, TRY_RUN then trys that .c file,
otherwise the existing CHECK_C_RUNS_SOURCE is preserved. I don't know
of any sane pathname that would be valid C code or vice versa, so
there should be no danger of passing in a C source snippit and having
it mistaken for a file path.

0012943: Make code groups in xcode match visual studio

Tue, 07 Feb 2012 17:28:50 -0500

We have a product where 2 of the platforms are windown and osx. The groupings of files in xcode should match visual studio.

I am submitting this in behalf of another engineer that left the company. I am submitting this myself because it is the only way to contribute changes back. OY!

Here is his explanation:

So the source group change fixed a problem specific to Xcode. It's possible to specify a "\\" delimited directory structure as a group name. So you can do the following:

source_group( foo foo.c)
source_group( foo\\bar bar.c)

In the VS generator that makes a group foo that contains a group bar and the file foo.c. The group bar contains the file bar.c This behavior is documented.

Those same lines in the the xcode generator create two groups. One is called foo and contains foo.c. The other is called "foo/bar" and contains bar.c. This behavior is not documented

The change corrects the xcode generator behavior to match that of the visual studio generator/documentation.

If memory serves... The code that was added iterates over the platform-independent source_group data structure the right way (which preserves nesting in a recursive fashion) rather than just enumerating every possible group and adding them without nesting. The diff should be helpful here, because I believe I checked the whole thing in as a single change.

0012940: FindBoost.cmake cannot find libraries built with clang on Darwin.

Tue, 07 Feb 2012 14:26:29 -0500

If boost libraries are built with clang, their compiler name ends up being clang-darwin instead of xgcc. Because of this, the script fails to locate them.

0012939: Several Build errors on Visual Studio

Tue, 07 Feb 2012 06:39:53 -0500

There were several build erros on Visual Studio.

I have fixed them. There is patch in attachment
Patch can be applied with command:
git am XDMF-Fixed-MS-Visual-Studio-build-errors_(Total_Changes)_(after_git_commit_65cd0ec1f0).patch

I have tested this patch on:
1. CentOS 5.6, gcc 4.1.2, x64
2. Windows 2008 R2, Visual Studio {2005,2008,2010}, x64

0007867: "Compiler Name" and "Compiler Version" are always unknown

Tue, 07 Feb 2012 05:12:57 -0500

CTest does not write compiler information into it's test result files so CDash always shows them as unknown.

0012938: Unable to persitently change "Enable" flag in CDash Schedule Build

Tue, 07 Feb 2012 04:01:09 -0500

When unticking the "Enable" check box in one of my build schedules and pressing the "Update Schedule >>" button the schedule is still run and when editing the schedule again the "Enable" check box is still ticked.

0012936: ExternalProject_Add - CMAKE_GENERATOR is not passing "-G" option properly

Tue, 07 Feb 2012 01:31:45 -0500

I have 2 CMAKE projects. I want one of them to compile as 64 bit application and other as 32-bit application. The 32-bit app is typically a tool that will be used in generating some sources required for the 64-bit compilation. Thats the scenario we have.
So, in the 64-bit app, i just "ExternalProject_Add" the 32-bit CMAKE project and use an appropriate generator, say "Visual Studio 9 2008", in the CMAKE_GENERATOR argument. I compile the 64-bit app from native x64 visual studio command prompt with "NMake Makefiles" generator - which builds in 64-bit mode.
The CMAKE configuration goes fine. When I do "nmake", I get into errors from devenv command -- resulting from cmake --build of the 32-bit project. devenv reports "Invalid solution configuration".
The reason is that the parent CMAKE passes "-GVisual Studio 9 2008" option to the child CMAKE instead of -G "Visual Studio 9 2008". This results in the child cmake using a bad configuration (instead of debug/release).

0012937: Broken 'headerlogo' link if 'Home URL' is not set

Mon, 06 Feb 2012 15:51:14 -0500

If the 'Home URL' for a CDash project is not set, the 'headerlogo' image link at the top-left corner of the project dashboard is set to "http://". [^]

Either disabling the link and showing a static image, or having the link redirect to the project's current CDash dashboard would solve the issue when 'Home URL' is not set.

0012934: Limitation on '=' in directory names is causing a problem

Mon, 06 Feb 2012 09:44:47 -0500

See the discussion at http://news.gmane.org/find-root.php?message_id=%3cE6F70BBF%2d3BCE%2d4AB8%2dA87D%2d1931E687DFE1%40users.sourceforge.net%3e [^]

Is this something that can ever be fixed?
Thanks.