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

[Óscar Fuentes]

Hello Doug. Glad to see my confidence on the sociability of the LLVM
developers restored ;-)

Douglas Gregor <dgregor at apple.com> writes:

>> Your patch switches from automatic to manually maintained library
>> dependencies. On the case of LLVM, that increases the workload of the
>> maintainer and it is the CMake equivalent of spaghetti code. Only a
>> strong benefit would justify that.
>
> There are numerous benefits to explicitly-maintained library dependencies:
> 	- It's clear what those dependencies are, which leads to better
> 	understanding of the system as a wholea

The file cmake/modules/LLVMLibDeps.cmake concentrates all those
dependencies, so if you want to get the whole picture of the library
dependencies, you have a single point to look at, instead of dozens of
files scattered all around the source tree.

It is possible to make that file more redable, if you wish.

> 	- Changes in dependencies, which are fundamentally architectural
> 	changes, become obvious when they happen

Again, looking at the history of LLVMLibDeps.cmake you can see all those
changes at a glance.

> 	- Dependencies can make their way into other tools far more
> 	easily, e.g., component-based CPack installers (e.g.,
> 	http://www.paraview.org/Wiki/CMake:Component_Install_With_CPack)

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.

> 	- It's clean and easy-to-understand, unlike our implicit
> 	dependency-generation scripts (and mapping from those to CMake
> 	dependencies)

Agreed.

> 	- On the "make" side of the world, explicit dependencies could
> 	improve build performance by exposing more
> 	parallelism. CMake-generated make files build faster than the
> 	autotools-generated makefiles, partly for this reason

Again, the just-committed system makes no difference here.

> For one, find_package is the standard CMake way of finding a package,
> so we should be providing that to CMake users.

That sounds good, but we shall think on terms of the specific
characteristics of LLVM. find_package works fine for libraries such as
zlib, that is, components that you install on standard places because
they are required by some other package and which are stable and remain
unchanged until a bug is found or a new version is required.

I don't think LLVM fits there. Either you have LLVM for working *on* it,
or you are tracking its development. In any case LLVM is not just "a
library," but THE library. And given how LLVM is developed you end
working with it as if it were work-in-progress, i.e. everything but
stable (in the sense of "frozen") not mentioning that you can easily end
with several installs around and wanting to use uninstalled builds
too. AFAIK find_package doesn't shine on those scenarios.

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

That said, I *think* that the automatic library dependencies system is
not an impediment for supporting find_package.

> CMake's export is designed to make it easy to get find_package working
> well, with versioning, the ability to directly depend on the exported
> project's targets, etc. One huge benefit to doing
> exporting/find_package well is that it would make it easier to
> separate the LLVM core from, e.g., Clang, because LLVM could export
> its targets and Clang could just import them via find_package. The
> rest of Clang's CMakeLists.txt files shouldn't have to change.

At some point on the past, I had a patch for doing that without the need
of find_package. It removed the requirement of putting clang under the
LLVM source tree. It wasn't committed because I wanted to improve some
aesthetics and becuase I didn't perceived too much enthusiasm about that
feature.

[snip]

> Michael has addressed the problems that cropped up. Do we know of any
> other problems that need to be addressed?

I haven't looked at the patch in detail, but my experience says that
issues will appear. This is not my main concern, though.

The issue here is that this patch goes against the main goal of the
CMake build as I implemented it: simple maintenance. As configure&&make
is the most used system by the developers, the CMake build will
inevitably go out of sync with the actual state of the source. So
easying the job of fixing it is paramount. On the case of a removed or
added source file the fix is easy, something anyone can do without
having a cmake build hence doable for those who use conf&&make. Not so
for a change on a library dependency: figuring out what's happening
*and* the optimal point for fixing the broken dependency is not so easy
and may require quite a few tentative builds. Furthermore, unnecessary
dependencis will accumulate either due to failures at reflecting the
optimal dependencies (i.e. putting the dependency on libraries A and B
when it should go to C) or due to dependencies which are no longer
required. This goes against your goal of having an easy way of seeing
the project structure. There are other more subtle cases of possible
brokenness, such as removed libraries that are forgotten on the list of
dependencies: the problem would only be visible if you do "make clean
all".

Overall, my opinion is that removing automatic library dependencies will
create more broken builds and will increase the time required for fixing
the breakage. It will be seen as a problem too if at some point someone
proposes to switch to CMake and ditch configure&&make (just remember how
much fuss was about explicitly adding and removing source files to the
build.) I think that the best thing we can do for our users is to
provide a reliable build, even if that requires renouncing to some nifty
features. At least until CMake is adopted as the official LLVM build.