Unexpected behavior for INSTALL directory

Code
1

I have added section in my script that handles adding third party DLL files to my install. It looks something like this:

install(DIRECTORY ${THIRDPARTY_BIN_DIR} 
DESTINATION "bin"
FILES_MATCHING PATTERN "*.dll")

The idea was all DLL files should be copied from the THIRDPARTY_BIN_DIR to the binary directory. In my case the THIRDPARTY_BIN_DIR is a variable found during configuration and looks something like this: c:\thirdparty\bin

However, when I run my script the third party DLL files do NOT end up in the bin folder. Instead a new folder bin is created inside the install bin folder and the files are added there. Like:
bin\bin\mylib.dll

This can be solved by adding a slash character to the source directory variable:

install(DIRECTORY "${THIRDPARTY_BIN_DIR}/"
DESTINATION "bin"
FILES_MATCHING PATTERN "*.dll")

Is this really the intended behavior or should I file a bug report?

2

Yes, the behavior is reminiscent of rsync's behavior with trailing slashes. The trailing slash basically means “the contents of” versus “the directory itself”.

2 Likes
3

Thanks! I found the corresponding description in the official documentation as well.

However, I still think that this behavior is non-intuitive. The most common case is probably that you want to copy files from the source folder to the destination folder, especially when you specify a file matching pattern. But this is only my personal opinion and I can certainly imagine other use-cases where the current behavior can be useful.

It was just yet another time for me where CMake “bit me in the behind” with unexpected behavior. :slight_smile:

4

While that may be true, both cases need support and, AFAIK, the “trailing slash” heuristic is the simplest available and has prior art in rsync (and now copied to rclone as well). If there’s a way that the docs could make this clearer, please feel free to contribute better wording.

Alas, CMake is old enough and has enough goobers in its history that I don’t think anyone runs out of these. The best we can do is make policies where possible and sensible and document everything (better) as they get discovered.

5

Alas, CMake is old enough and has enough goobers in its history that I don’t think anyone runs out of these. The best we can do is make policies where possible and sensible and document everything (better) as they get discovered.

As someone who has used CMake since 2009, I can also testify to that. However, I must commend the current developers for the huge improvement in the quality of documentation in recent years.

1 Like
6

Do you mind if I create an issue in CMake repo and try to fix it?

7

@leha-bot Since the current behavior is documented and similar to other tools (RSync) I don’ think the current behavior should be considered a bug. Changing the behavior will probably lead to unexpected failures for others who depend on the current behavior.

8

Aggreed, but I think that the documentation still need a fix :blush: so the bug will be about documentation fixes

9

Doc fixes are always appreciated :slight_smile: .

1 Like