[LLVMdev] Some CMake issues (Are you being served?)

[NAKAMURA Takumi]

Stephen,

> 1) You need to set the minimum required CMake version before the project()
> command.

Fixed in r200645.

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

Fixed in r200643 and r200644.

> 3) In modern cmake code, the end*() commands have no content. See eg
>
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9db31162

In historical reason, IMO, I'd not like to substitute all of them.
We will prune such legacy phrases whenever we touch around them.


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

Brad King is proposing the stuff. Excuse me we haven't accepted his yet.
See also http://llvm.org/bugs/show_bug.cgi?id=15732


> 5) When I see things like this:
>
>  add_dependencies(clangStaticAnalyzerCheckers
>    ClangAttrClasses
>    ClangAttrList
>    ClangCommentNodes

They give dependencies for generated headers. What'd be wrong to you?

I have w-i-p patchset to nuke them (to go more suboptimal)

> and this:
>
>  set(LLVM_LINK_COMPONENTS
>   Support
>  )

LLVM_LINK_COMPONENTS is for compatibility of autoconf build.
In AddLLVM.cmake and LLVM-Config.cmake, it is translated to
target_link_libraries.

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

You may suppose the former is coming from historical reason. Please be patient.

The latter, I am certain CMake is insufficient.
I know it'd be not easy to describe optimal behavior for generated headers.

FYI, ClangXXX is doing;

  1. Generate clang-tblgen.
  2. Generate foo.inc from foobar.td.
  3. Build object files with generated foo.inc.

Do you think we should give suboptimal dependency,
"Build all files whenever any of *.td were touchd"?


> 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

Most of us are building clang in llvm build tree.
Aka "standalone clang" could be supposed as w-i-p.
I think other projects could be good studies for external cmake build.

I agree to update cmake version if LLVMConfig.cmake would work more smart. ;)


...Takumi