I work on CMake upstream. I'd like to find out in what ways CMake upstream
does not fit the needs of llvm/clang, and then fill those gaps. The recent
update of the minimum version to CMake 2.8.8 is a good start. Before being
able to assess what is missing, it should be ensured that the current
codebase is as modern as the minimum version allows, and it needs to be
1) You need to set the minimum required CMake version before the project()
The minimum version affects behavior by setting policies, and can
affect the behavior of the project() command.
You need to do the same in clang/CMakeLists.txt.
2) You need to clean up tabs vs spaces. At least clang/CMakeLists.txt mixes
them. I didn't look elsewhere but you should clean it all up.
3) In modern cmake code, the end*() commands have no content. See eg
You can run a similar command on the llvm cmake files. At least clang
endif(MSVC_IDE OR XCODE)
I didn't check others.
4) There seems to be a 'cmake package config file' generated by the llvm
(the doc is new in master, but it applies almost entirely to CMake 2.8.8
but it doesn't seem to appear in my llvm-3.5-dev ubuntu package.
You need to ensure that the package config file is generated by your
buildsystem. If you support two buildsystems, you need to ensure that it is
generated properly by both of them. As far as I can see, the Makefile
buildsystem in llvm does not generate the files. This is a significant bug.
It is equivalent to not generating a required header file in one of your
You need to ensure that the config file is generated by both buildsystems.
That can mean that you avoid the built-in CMake facilities for creating
[Sidebar: This is part of the reason why I strongly recommend any project to
have only one buildsystem. If it is impossible for you to drop the Makefile
system, then consider dropping the CMake one. It creates false expectations
of ability to use packages downstream.]
5) When I see things like this:
I don't know what those lines are for, but it looks like 'you're doing it
wrong' from a dependency specification point of view, or CMake is not giving
you the interfaces to do it right. If it's the latter, I want to fix that.
6) If you create a proper config file, then you can populate it with
IMPORTED targets and use it in clang. IMPORTED targets record dependencies
and usage requirements (when you start requiring CMake 2.8.9+ at least)
The main oddness seems to come from the fact that the Makefile buildsystem
doesn't create the cmake package config files. Fix that first or remove the
Makefile buildsystem. I recall there was a discussion about that a few years