Mantis - ISSUES

0009992: Install dir on Win64 always starts with c:/program files (x86)/ regardless of architecture of build

The issue here is that CMAKE_INSTALL_PREFIX seems to be using the %ProgramFiles% environment variable to set this, which is problematic: on win64 machines, the WOW64 subsystem transparently changes this environment variable to point to the program files dir that matches the architecture of the running application (in this case, CMake-Gui though I presume cmake itself has the same issue). When building a 64-bit application (using a 64-bit generator), this results in an incorrect install prefix and potentially broken/weird installers.

Here's the logic and comments I wrote in a CMake module related to this that describes the solution - _PROGFILESDIR at the end of this code contains the correct "prefix" for the install prefix:

# caution - ENV{ProgramFiles} on Win64 is adjusted to point to the arch of the running executable
# which, since CMake is 32-bit on Windows as I write this, will always be = $ENV{ProgramFiles(x86)}
# so we only use this environment variable if we figure out we're on win32
file(TO_CMAKE_PATH "$ENV{ProgramFiles}" _PROG_FILES) # 32-bit dir on win32, useless to us on win64
file(TO_CMAKE_PATH "$ENV{ProgramFiles(x86)}" _PROG_FILES_X86) # 32-bit dir: only set on win64
file(TO_CMAKE_PATH "$ENV{ProgramW6432}" _PROG_FILES_W6432) # 64-bit dir: only set on win64

if(CMAKE_SIZEOF_VOID_P MATCHES "8")
# 64-bit build on win64
set(_PROGFILESDIR "${_PROG_FILES_W6432}")
else()
if(_PROG_FILES_W6432)
# 32-bit build on win64
set(_PROGFILESDIR "${_PROG_FILES_X86}")
else()
# 32-bit build on win32
set(_PROGFILESDIR "${_PROG_FILES}")
endif()
endif()

0004501: vtkTextActor does not allow any encoding, only supports plain ASCII.

Currently, vtkFreeTypeUtilities is used to render text from a vtkTextActor. The string is parsed character by character using a char*. It only supports plain ASCII as it does not allow to use multiple bytes encoding. Therefore, it is not possible to display some french or other europeen characters such as accents.

0011192: FindBoost expects hyphen in directory name when it should be an underscore

I can't seem to find this reported elsewhere, but the Boost libraries cannot be found under Linux (Debian). After specifying -D Boost_DEBUG=ON, I realized it is searching in these paths:

-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:500 ] _boost_PATH_SUFFIXES = boost-1_42;boost-1_42_0;boost-1_41_0;boost-1_41;boost-1_40_0;boost-1_40;boost-1_39_0;boost-1_39;boost-1_38_0;boost-1_38;boost-1_37_0;boost-1_37;boost-1_36_1;boost-1_36_0;boost-1_36

However, if you download v1.42 (and also the current 1.44 -- I just checked) as a .tar.gz file, it gets installed in boost_1_42_0. i.e., the first dash should be an underscore.

0011217: find_package description

There isn't any reference on documentation how to retreive in "module" mode all parameters passed to find_package( params ..) inside the Find.cmake file.

0010436: add search pattern to findpackage boost

Hi,

I have recently installed boost from

http://ascendwiki.cheme.cmu.edu/Binary_installer_for_Boost_on_MinGW [^]

To this package with cmake I had to add the following line to FindBoost.cmake
(In the FIND_LIBRARY call)

${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}

(cannot create a patch, since this is windows, but it should be obvious).

Please add this pattern to the next distributed version of cmake.

0008412: Setting BOOST_ROOT does not guarantee boost libraries detected outside BOOST_ROOT are the correct ones

If detecting of Boost libraries in BOOST_ROOT fails for some reason, FindBoost will continue on searching the system paths and other CMake paths. Since FindBoost includes in its FIND_LIBRARY() calls filenames of the Boost libraries without Boost version in them (e.g. libboost_datetime.so) what can happen is that these libraries get detected (which may be for an older version of Boost) but the detected include path is for a newer version of Boost.

0011019: FindBoost: Potential incoherent behavior when BOOST_ROOT is set and there is a boost installation in system directories

This is a duplicate of bug 9447 but since I am not the initial reporter, I cannot reopen it.

I have a system installation of boost 1.40 for my package manager on ubuntu but want my project to be compiled against a local boost package (version 1.42).

By default, If I only specify BOOST_ROOT, FindBoost will get the include dir correctly but will take the libraries from /usr/lib.

The reason is because my local boost copy does not have the "-mt" libraries, e.g.
- local has libboost_regex.a libboost_regex.so libboost_regex.so.1.42.0
- system has /usr/lib/libboost_regex.a /usr/lib/libboost_regex-mt.so /usr/lib/libboost_regex.so.1.40.0 /usr/lib/libboost_regex-mt.a /usr/lib/libboost_regex.so

Setting Boost_USE_MULTITHREADED to OFF solves the problem.

I do however still consider this to be a bug since no warning is issued and the advice in bug 9447 did not solve my problem.

0011187: Cmake unable to find several Boost libraries

I am not really a developer so I hope you can help. I am trying to build the UHD-API for a student project. I am having trouble building the project file before I attempt to compile it. I have seen from another issue (0009510) that there is an existing problem that will be fixed in the next release of Cmake. However, I would really appreciate it if someone were to offer me a work around. I have installed boost 1.44 and have added the version to the FindBoost.cmake as per the instructions in the file. I am unable to use earlier versions of boost or the Cmake 2.6.x because it will not work with the MSVS2010 compiler that I need to use. I have added the BOOST_INCLUDEDIR BOOST_ROOT CMAKE_INCLUDE_PATH CMAKE_LIBRARY_PATH etc to point to the appropriate locations, but in spite of this, I am getting the following error when I hit 'Configure' :

CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:910 (message):
Unable to find the requested Boost libraries.

Boost version: 1.44.0

Boost include path: C:/Program Files/boost/boost_1_44

The following Boost libraries could not be found:

boost_date_time
boost_filesystem
boost_program_options
boost_regex
boost_system
boost_thread
boost_unit_test_framework

No Boost libraries were found. You may need to set Boost_LIBRARYDIR to the
directory containing Boost libraries or BOOST_ROOT to the location of
Boost.
Call Stack (most recent call first):
CMakeLists.txt:85 (FIND_PACKAGE)

Thanks and Best Regards,
Sanat.

0011121: FindBoost does not work with DLLs with 'lib' filename prefix

When building boost it generated the following library files:

libboost_thread_win32-mgw45-mt-1_43.a
libboost_thread_win32-mgw45-mt-1_43.dll
libboost_thread_win32-mgw45-mt-1_43.dll.a
libboost_thread_win32-mgw45-mt.a
libboost_thread_win32-mgw45-mt.dll.a

FindBoost.cmake does not work when called with the thread component, however, because it does not expect to see _win32 inserted into the filename.

I had to make symlinks such as 'libboost_thread-mgw45-mt.dll.a' to get it to work.

0011204: FindBoost.cmake has trouble discovering libraries when both -sgd and -gd libraries are available

When specifying the Boost_USE_STATIC_LIBS to ON, the module won't find the -sgd libraries if the -gd libraries are present. I fixed this by switching the order that they're searched for, looking for the more specific library first before the more general one, which seems to have fixed the issue.

0010735: Passing Paths containing colons through ExternalProject_Add's CMAKE_ARGS argument

This is only relevant to the first argument passed through the CMAKE_ARGS argument of ExternalProject_Add. If the first argument passed is a path (for example) and this path contains a colon, as in 'd:/path/to/somewhere' all that will be passed through is 'd:'

I have an example that I have put together to illustrate this problem. If you decompress and untar the attached tar.gz file you should be able to see for yourself. I have highlighted the message output by wrapping the relevant messages in ??????????????????????? so it should make things easy to spot. also if you execute the application that is built it will also display the problem paths.

I won't bother myself explaining to you how to run cmake, but if I have done anything wrong I am happy to help.

I have tested this on windows only, as this is the place where I use colons in paths.

0009618: Differences in display of vtkTextActors between vtk5.0.4 and vtk5.4.2 (shadow and accentuated characters)

Two problems when rendering vtkTextActor:
- the shadow property looks strange in 5.4.2 (and 5.2.1) compared to 5.0.4
- accuentuated characters (é, è...) are no longer displayed in 5.4.2 (and 5.2.1)

Note : all vtk version were compiled with VC++2005 under WinVista, with the same options.

Below is the sample code that produce.
Joined a zip file with output images for 5.4.2 and 5.0.4.

0010611: VS2010 generator doesn't handle executable names with periods.

The following CMakeLists.txt file:

PROJECT(AAA)
ADD_LIBRARY(AAA.BBB.CCC SHARED File1.cpp)

, when built with VS2010, will produce the executable AAA.dll, rather than AAA.BBB.CCC.dll.

I'm using cmake 2.8.1. I've tried the VS2008 generator and it does not have this problem.

0011038: rendering through OSmesa does not work on multiple nodes

I compiled paraview 3.8 (pvbatch) without X and with OSmesa support to run on the university cluster. When I submit a pvbatch job it works fine on just 1 node of the cluster (max 8 procs) however the rendering goes wrong when using 2 or more nodes on the cluster. See the attached .png files.

0010201: FindSubversion: new Subversion_WC_UPDATE macro

I asked on the mailing list if there would be any interest in a Subversion_WC_UPDATE macro. At least one reader was interested, so I'm donating my macro to the community, so that others may benefit and improve it. And maybe, someday, it will make it into the FindSubversion.cmake macro.

0011216: Link with /MANIFEST even /manifest:no was set

I comment out
#SET(CMAKE_START_TEMP_FILE "")
#SET(CMAKE_END_TEMP_FILE "")
#SET(CMAKE_VERBOSE_MAKEFILE 1)
in file
C:\Programme\CMake 2.8\share\cmake-2.8\Modules\Platform\Windows.cmake
and found a /MANIFEST at the end of the link command, although i have set "/manifest:no". At least i found the reason at line 4250 of cmake.cxx where an unconditioned
linkCommand.push_back("/MANIFEST");
occured. I would suggest to put it in the condition hasManifest as propageted in the attached patch.

Jörg

0011160: FindBoost to retrieve realpath of the boost libraries

Hello,

I would like to install some of the boost components with cpack from my cmake project.
In order to create a package on Linux targets, I use for instance the following commands:

set(BoostFilesToInstall
${Boost_PYTHON_LIBRARY_RELEASE}
${Boost_SYSTEM_LIBRARY_RELEASE}
${Boost_GRAPH_LIBRARY_RELEASE}
)
install(FILES
${BoostFilesToInstall}
CONFIGURATIONS Release
DESTINATION lib
COMPONENT libraries)

However, FindBoost retrieves the links to the boost compiled libraries, rather than the files
pointed by these links. The building of a debian/mac os bundle package complain about that.
I am not 100% sure but I think cpack is trying to install the links rather than the files themselves.

So I was wondering if it would be possible to have as ${Boost_XXX_LIBRARY} libraries the result of
get_filename_component(Boost_XXX_LIBRARY ${Boost_XXX_LIBRARY} REALPATH). This way, the package would
be consistent and the dependant libraries in my project will link with boost libraries named explicitely
with their version, compiler etc.

Do you think it is a good thing to have, or the fact that using the link name is desired behaviour ?

Kind regards,
Raffi Enficiaud

0008529: FindBoost is unable to detect Boost libraries compiled against STLport

As reported on the CMake mailing list, FindBoost is unable to detect Boost libraries compiled against STLport.

http://www.boost.org/doc/libs/1_38_0/more/getting_started/windows.html#library-naming [^]

0009284: macosx BundleUtilities.cmake - fixup_bundle fails in some cases

Bundle verification fails with some libraries when I want to build a bundled app on macosx.

output:

-- 16/28: fixing up '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/Libraries/libcrypto.0.9.8.dylib'
install_name_tool: can't open input file: /Users/pvanek/oss/tora/bundle/TOra.app/Contents/Libraries/libcrypto.0.9.8.dylib for writing (Permission denied)

it's clear that this library has -r-xr-xr-x permissions.

The verification procedure should check and change dylibs privileges (and potentially restore it after fixup), shouldn't it?

0009744: BundleUtilities making extra copies of plugins

Extra copies of plugins were incorrectly being made and put in the bin/ folder. On the Mac, it led to fixing up the wrong copy. So some Qt apps on Mac that use plugins don't work right.

Just setting the copy flag = 0 as is done for executables fixes the problem.

Index: BundleUtilities.cmake
===================================================================
--- BundleUtilities.cmake (revision 41975)
+++ BundleUtilities.cmake (working copy)
@@ -351,7 +351,7 @@
# but that do not show up in otool -L output...)
#
foreach(lib ${libs})
- set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 1)
+ set_bundle_key_values(${keys_var} "${lib}" "${lib}" "${exepath}" "${dirs}" 0)

set(prereqs "")
get_prerequisites("${lib}" prereqs 1 1 "${exepath}" "${dirs}")

0010417: BundleUtilities/GetPrerequisites not doing bundleutilities example correctly

There is an example here:
http://www.cmake.org/Wiki/BundleUtilitiesExample [^]

That doesn't work correctly.

There are two problems.

1.
otool -L also returns the install id, if it exists, which means get_prerequistes can return the target itself as a dependency of the target. This causes problems for BundleUtilities.cmake.
The attached patch fixes this.

2.
BundleUtilities.cmake makes the assumptions that plugins have to reside in the same directory as the executable. In the example, the Qt plugins have a special layout.

Attached patch fixes both issues.

0010176: Add Support for IAR compiler

Add support for IAR compiler. CMakeCCompilerId.c.in has such definition already
/* IAR Systems compiler for embedded systems.
http://www.iar.com [^]
Not supported yet by CMake
#elif defined(__IAR_SYSTEMS_ICC__)
# define COMPILER_ID "IAR" */

0011215: UseSWIG.cmake creates $(OutDir) directory

I'm setting CMAKE_SWIG_OUTDIR manually because I want the .py files swig generates to be in the same directory as the dll/pyd file.

So I set CMAKE_SWIG_OUTDIR to "${LIBRARY_OUTPUT_PATH}/bin/${CMAKE_CFG_INTDIR}"
But UseSWIG.cmake will create a "../bin/$(OutDir)" directory, as opposed to "../bin/Release" or "../bin/Debug" just because the $(OutDir) directory doesn't exist.

0010740: STRING(SUBSTRING) should work with length -1

I would like to cut the first character from a string. This means I have to query the string length, substract one and then call:

STRING(SUBSTRING "foo" 1 ${LENGTH} FOO_OUT)

It would be very useful to have a simple way to delete the first N and last N characters. The first could happen by allowing -1 as length:

STRING(SUBSTRING "foo" 1 -1 FOO_OUT) -> "oo"

The other operation could be something like

STRING(CHOP "foo" 1 FOO_OUT) -> "fo"

0011213: VC2010 Generator handles CMAKE_MFC_FLAG incorrectly

I noticed this issue when moving some of our projects to VS2010/Cmake 2.8.2. In previous versions (and the VC 2008 generator), the CMAKE_MFC_FLAG specified how MFC was used. This is mapped as follows:
0 - not using MFC
1 - using MFC statically
2 - using MFC dynamically

I've noticed that the VC2010 generator simply checks for the existence of the CMAKE_MFC_FLAG variable, and writes out "true" or "false", ignoring the actual value of the flag (I've verified this by looking at the source). While this allows me to disable use of MFC by not defining the flag, it does not allow me to specify how mfc should be used.
I believe the correct values in VC2010 are "false", "static", and "dynamic". The CMAKE_MFC_FLAG values should map to these strings. In fact, it might even make sense to have the CMAKE_MFC_FLAG use the values "false", "static", and "dynamic" itself, instead of the unclear numbering system found in previous versions of VC projects.