change in CMake variable names breaks existing uses and does not conform to CMake conventions

Hi Chris and everyone else,

I just noticed that some of my builds broke due to commit 280013, as LLVM_INCLUDE_DIRS was renamed to LLVM_INCLUDE_DIR. In and of itself, not much of an issue as the fix is just to remove one character (in a couple of places). However, I would like to discuss if this rename is desirable at all. Sure, in-tree LLVM_INCLUDE_DIR is used everywhere, however not providing an ${NAME}_INCLUDE_DIRS variable goes against CMake conventions. See for example the find scripts included with CMake itself: → provides ZLIB_INCLUDE_DIRS (and not ZLIB_INCLUDE_DIR) even though it is typically only one directory

And the same holds true for most other Find${NAME}.cmake scripts I had a look at (Boost, Bullet, CUDA, Freetype, XMLRPC, Zlib). I’ll admit there are 1 or 2 exceptions (such as OpenGL) but in general I think it would be better to stick to the more common/conventional case.




Fraunhofer-Institut für Graphische Datenverarbeitung IGD

Fraunhoferstr. 5 | 64283 Darmstadt | Germany

Tel +49 6151 155-606 | Fax +49 6151 155-139 |

Hi Everyone, (resending because I can’t get the hang of Reply All)

I second Johannes.

cmake’s own Find* man page suggests using the _DIRS variant “to keep things consistent”:

Granted, we’re supporting Config-mode and not Module-mode, but i think the variable name rules should still apply for consistency.


Hi Philip,

thanks for the hint about the man page. Totally forgot about that.

Even though Config-mode generally has different rules, we don’t truly support that anyways as none of the exported targets have the INTERFACE_INCLUDE_DIRECTORIES (in which case the LLVM_INCLUDE_DIRS variable would become unnecessary anyways).



Brad King brought this up on the commit thread, and I replied telling him I would bring back the old names.

The reason behind the change is that we’re currently blurring the lines between in-tree and out-of-tree builds, and we need to have consistent interfaces for projects.

Either way, both names are supported with r280380.