Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Stephen Kelly <steveire <at> gmail.com>
Subject: Some CMake issues (Are you being served?)
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Sunday 2nd February 2014 08:09:59 UTC (over 3 years ago)
Hello,

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 
cleaned up.

1) You need to set the minimum required CMake version before the project() 
command.
    
The minimum version affects behavior by setting policies, and can
affect the behavior of the project() command.
    
 http://www.cmake.org/cmake/help/git-master/manual/cmake-policies.7.html
    
Eg
    
 http://www.cmake.org/cmake/help/git-master/policy/CMP0025.html

-project(LLVM)
 cmake_minimum_required(VERSION 2.8.8)
+project(LLVM)

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 

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9db31162

You can run a similar command on the llvm cmake files. At least clang 
CMakeLists contains 

 endif(MSVC_IDE OR XCODE)

I didn't check others.

4) There seems to be a 'cmake package config file' generated by the llvm 
build.

 http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#package-configuration-file

 (the doc is new in master, but it applies almost entirely to CMake 2.8.8 
too)

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 
supported buildsystems.

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 
packages.

[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:

 add_dependencies(clangStaticAnalyzerCheckers
   ClangAttrClasses
   ClangAttrList
   ClangCommentNodes

and this:

 set(LLVM_LINK_COMPONENTS
  Support
 )

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) 
properly.

 http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html#imported-targets


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 
ago.

Thanks,

Steve.
 
CD: 4ms