MantisBT - CMake
View Issue Details
0013177CMakeCMakepublic2012-04-30 16:142013-01-09 10:58
Braden McDaniel 
Brad King 
normalmajoralways
closedfixed 
x86_64Mac OS X10.7.3
CMake 2.8.7 
CMake 2.8.9CMake 2.8.9 
0013177: File matching patterns not functional when installing headers
In the course of trying to build mysql-c-connector-6.0.2, I found that the following directive does *not* result in header files being installed by "make install":

INSTALL(DIRECTORY "include/"
        DESTINATION "include"
        FILES_MATCHING PATTERN "*.h")

Changing to this results in "make install" installing the headers:

INSTALL(DIRECTORY "include/"
        DESTINATION "include")
I was unable to reproduce this problem on Fedora 16 Linux. However, it happens consistently on Mac OS X 10.7.3 using MacPorts CMake.
No tags attached.
has duplicate 0010366closed Brad King install(DIRECTORY ... ) FILES_MATCHING does not work on MacOS 
Issue History
2012-04-30 16:14Braden McDanielNew Issue
2012-05-01 14:22Brad KingNote Added: 0029383
2012-06-11 13:46Matthew McCormickNote Added: 0029659
2012-06-11 13:50Matthew McCormickNote Added: 0029660
2012-06-11 14:02Brad KingNote Added: 0029661
2012-06-12 08:25Brad KingNote Added: 0029665
2012-06-13 08:59Brad KingNote Added: 0029682
2012-06-13 08:59Brad KingAssigned To => Brad King
2012-06-13 08:59Brad KingStatusnew => resolved
2012-06-13 08:59Brad KingResolutionopen => fixed
2012-06-13 08:59Brad KingFixed in Version => CMake 2.8.9
2012-06-13 08:59Brad KingTarget Version => CMake 2.8.9
2012-08-13 15:40Brad KingRelationship addedhas duplicate 0010366
2013-01-09 10:58Robert MaynardNote Added: 0032057
2013-01-09 10:58Robert MaynardStatusresolved => closed

Notes
(0029383)
Brad King   
2012-05-01 14:22   
I cannot reproduce this, at least on OS X 10.6:

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.6.6
BuildVersion: 10J567

$ /opt/local/bin/cmake --version
cmake version 2.8.7

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(Issue13177 C)
install(DIRECTORY "include/"
        DESTINATION "include"
        FILES_MATCHING PATTERN "*.h")

$ find ../include -type f
../include/a.h
../include/b.h
../include/c.H

$ /opt/local/bin/cmake .. -DCMAKE_INSTALL_PREFIX="$(pwd)/prefix"

$ make install
Install the project...
-- Install configuration: ""
-- Installing: .../prefix/include
-- Installing: .../prefix/include/a.h
-- Installing: .../prefix/include/b.h
-- Installing: .../prefix/include/c.H

Note that even case-insensitive matching works. Also, our test suite contains almost the exact same case:

  http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/SimpleInstall/CMakeLists.txt;hb=v2.8.7#l272 [^]

and passes on all OS X nightly test machines.

Please provide a minimal but complete source tarball that demonstrates the problem. Also please try to reproduce this with an upstream CMake to ensure MacPorts patches do not interfere.
(0029659)
Matthew McCormick   
2012-06-11 13:46   
This bug was also encountered with DCMTK. For more information, see

  http://massmail.spl.harvard.edu/public-archives/slicer-devel/2012/009020.html [^]
  http://massmail.spl.harvard.edu/public-archives/slicer-devel/2012/009033.html [^]
(0029660)
Matthew McCormick   
2012-06-11 13:50   
Also note from reports on DCMTK thread: the command appears to behave correctly with CMake 2.8.2 from Debian.
(0029661)
Brad King   
2012-06-11 14:02   
Re 0013177:0029660: As stated in 0013177:0029383 the command also appears to work as documented on ALL our nightly testing machines, and on my machines. It is a tested feature.

There must be something obscure about the conditions that lead to the failure.
(0029665)
Brad King   
2012-06-12 08:25   
Re 0013177:0029659: From discussion with the reporter of the problem in DCMTK it happens on all their OS X 10.7 machines.
(0029682)
Brad King   
2012-06-13 08:59   
I discovered the problem occurs when the install source directory is a mixed-case file path on a case *sensitive* filesystem on a Mac. This fixes it:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a41557a2 [^]
(0032057)
Robert Maynard   
2013-01-09 10:58   
Closing resolved issues that have not been updated in more than 4 months.