[llvm-commits] [PATCH][CMake] Removing LLVMLibDeps.cmake and exporting libraries for CMake clients.

[Óscar Fuentes]

Douglas Gregor <dgregor at apple.com> writes:

> If you want the whole picture, it's slightly better to have one large
> list of dependencies. That said, text is a horrible format for such a
> task, and it's far more likely that someone wanted to look at the
> whole picture would actually want a picture, e.g., as generated by
> GraphViz.

Again, extracting GraphViz data or XML describing dependencies from
CMake is unaffected by the automatic dependency system.

> I do have a few issues with putting all of the dependencies in a single file:
>
> 	1) People forget about it when they make changes. LLVM
> 	developers have gotten fairly good at updating CMakeLists.txt
> 	when they change the corresponding makefile (finally!), because
> 	they live alongside the Makefiles. This other file off in an
> 	apparently-unrelated subdirectory gets forgotten.
>
> 	2) Most of the time, we want to reason about dependencies
> 	locally ("I added this feature, and now my library depends
> 	on..."), and a single file makes that harder.

If explicitly keeping library dependencies are so good, why do you keep
using the llvm-config script on the configure&&make build? Why
llvm-config was introduced on the first place?

> 	3) It's unclear how a "single file" works for multiple
> 	projects. For example, LLVMLibDeps didn't have Clang's
> 	dependencies, because Clang is in a different repository. Should
> 	Clang have its own ClangLibDeps? Should they all be merged
> 	together? We actually had a mix of LLVMLibDeps dependencies and
> 	per-CMakeLists.txt dependencies.

Since I implemented the CMake build on Clang, I lost touch with
it. Hence can't comment. But I don't see how the existence of
LLVMLibDeps is an inconvenience for Clang.

[snip]

>> CPack works fine with the automatic library dependency system. Please
>> note that the automatic system ends using target_link_libraries anyways,
>> so putting it explicitly on the corresponding CMakeLists.txt makes no
>> difference for tools that require its existente.
>
> I'm specifically referring to dependencies in component-based
> installers, which are separate from those dependencies and can be at a
> higher level of granularity (e.g., dependencies between groups of
> libraries in the graphical installer).

Again, this is independent of where you put target_link_libraries, on
each CMakeLists.txt or on some .cmake script.

> My understanding of CMake's export feature is that it helps with this,
> too; you can use CMake variables to push find_package toward, for
> example, a build tree of LLVM in your project that depends on LLVM.

In any case, this shall be documented on docs/CMake.html, with examples
for the case of multiple installs. I wouldn't never approve the change
until it includes updates to the documentation.

>> For the average user, I don't think that find_package offers significant
>> advantages over the method documented in
>> 
>> http://www.llvm.org/docs/CMake.html#embedding
>
> I think the advantage is familiarity; we'd fit better into the general
> CMake ecosystem if we follow their conventions.

I'm more concerned about fitting into the LLVM ecosystem :-)

[snip]

> Mistakes can creep in anywhere, and when we find them, we'll fix them.

The point about the automatic system is that it avoids mistakes and
makes fixes unnecessary.

[snip]

> Let's say that we adopt CMake as the official LLVM build system
> tomorrow. Would you still want implicit dependencies, or would you
> then favor explicit dependencies?

I think that automatically updated library dependencies ("implicit" is
not the right word, as they are very explicitly stated on
LLVMLibDeps.cmake) saves work and are more accurate than manually
mantained ones. If you want to stay on touch with the structure of the
project, you look at LLVMLibDeps.cmake or ask CMake for a XML or
GraphViz file that describes it.

Doug, if you are so convinced about the virtues of manually maintained
library dependencies for LLVM, go ahead, keep the change on the
repo. After all, if I'm right about my concerns it doesn't mean complete
disaster. But I'll like to be sure that you are not basing your decision
on false premises and that you are aware of the social and workload
implications. I know you are committed to a high quality CMake build and
possibly can devote more energy than me to that cause. So I'm willing to
silence my opposition and pass the responsibility of driving the
evolution of the CMake build to you and others who have their own ideas
and want to see them materialized. I hate to stop people from doing
things and think that I can't always keep others from making
mistakes. Not to mention that sometimes it is me who is mistaken ;-)