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

[Óscar Fuentes]

Michael Spencer <bigcheesegs at gmail.com> writes:

>> Uh? What those extra library dependencies are and why they do require
>> modifications to LLVMLibDeps.cmake? Please provide an example.
>
> When I added LLVMObject, I had to go and add the following to LLVMLibDeps.cmake:
>
> set(MSVC_LIB_DEPS_LLVMObject LLVMSupport LLVMSystem)
>
> Apparently this file can be automatically generated, but only on non
> Windows platforms with all targets enabled, neither of which I do.

Well, so you had to add a line to a file. It doesn't seem a big
issue. (And last time I tried it is possible to regenerate
LLVMLibDeps.cmake with MinGW/MSYS on Windows)

Anyways putting

target_link_libraries(object support system)

on libs/Obect/CMakeLists.txt would do too until some *nix guy
regenerates the dependencies, unless there are other LLVM libraries that
depend on LLVMObject.

>> 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.
>
> Currently we have a mess of both. Some targets use
> target_link_libraries,

No targets should use target_link_libraries for dependencies on LLVM
libraries, except perhaps some utilities like tblgen.

> and others use LLVM_LINK_COMPONENTS. We already
> have to manually maintain LLVMLibDeps.cmake. In fact just recently
> someone forgot to commit that file when they made other changes.

It is very different to have to commit a file than to wade through
several files updating dependency lists. Take a look at the svn history
of LLVMLibDeps.cmake and you can get an idea of the amount of work. And
that only shows the changes caused by committed changes on the
libraries.

> My proposal is hardly spaghetti code. It's the same thing as #include.
> Should compilers just look at all of the header files and pick which
> ones to include automatically?

Certainly, it would be a nice feaure :-)

The current system is not doing exactly that, though. You pass a list of
top-level component names and LLVMConfig.cmake figures out the list of
required LLVM libraries.

> With target_link_libraries, you only have to specify which libraries
> the target _directly_ needs to link to. Any other libraries will be
> pulled in because CMake knows about the dependencies.

Right, but then you need to maintain dependencies on the 76
CMakeLists.txt files under lib/. Figuring out on which library the
missing reference resides is not a straightforward task, contrary to
just re-running the build.

>> How is that better than
>>
>> http://www.llvm.org/docs/CMake.html#embedding
>
> Because it is the standard CMake way of doing things. It allows
> trivial selection between multiple versions. It is also simpler in the
> case of finding non-installed builds without worrying about in/out of
> source builds. It is not sensitive to location changes.

I'm not familiar with EXPORT, so maybe you are right here. A different
issue is the compatibility of EXPORT with the current dependency system.

>> ? Think that it is usual practice to have and use multiple LLVM builds
>> with different configurations on the same system.
>
> find_package easily supports this. In fact, if you have both a Release
> and Debug build of LLVM installed, it will automatically choose the
> correct build based on your own current build type.

How? If I have d:/libs/llvm/vcr, d:/libs/llvm/vcd, d:/libs/llvm/mr,
d:/libs/llvm/md, etc (for (r)elease and (d)ebug builds on (m)ing and
(v)visual (c)++) how it knows which to pick? And if I add to that
another variant: (s)table, (t)esting and (t)ip builds? I see no way of
sorting out that conundrum except for explicitly passing the path to the
install or build I want to use. And then find_package is useless.

> I agree it needs to be well tested. Currently the only platform that
> it has yet to be tested on is OS/X.

Just to be clear: by "testing" I don't mean to run the default build to
see if it completes. It consists on trying combinations of at least the
most popular variables and options, which includes BUILD_SHARED_LIBS
(where supported) CMAKE_BUILD_TYPE, etc and the LLVM-specific variables
listed on http://www.llvm.org/docs/CMake.html

Yes, I know it is a lot of time. Being there, done that.