[llvm-dev] llvm-9-dev apt package missing yaml-bench

Stefan Gränitz via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 4 07:14:47 PST 2019

On 04/12/2019 08:40, Sylvestre Ledru wrote:
>>> It should be indeed in llvm-9-dev instead.
>> This would hide the problem, right. I am not sure it's is a good
>> solution.
> why?
llvm-9-dev is for people who use LLVM as a library. They shouldn't need
yaml-bench. It's what we use for benchmarking LLVM itself right?
The same goes for the other utils (FileCheck, count, not, etc.) that we
use for testing. People who need it get llvm-9-tools. Furthermore
llvm-9-dev shouldn't depend on llvm-9-tools right? This was a workaround

IMHO the underlying problem is that we pass LLVM_INSTALL_UTILS here:

The flag does both, create install targets for the utils and add them to
the exports list. This makes a lot of sense for LLVM sub-projects, which
make use of the testing infrastructure. They can import these targets
and use the binaries without having to check whether they build against
a build-tree or an install-tree of LLVM. We added this behavior during
the 9.0 cycle and I think it's worth keeping. Before that all the
sub-projects were guessing the utils' paths.

It looks like the debian/rules makefile populates one monolithic
install-tree and partitions it into the separate packages. The utils
must be there in order to populate the llvm-9-tools package. From this
point of view LLVM_INSTALL_UTILS makes sense. The LLVMExports.cmake,
however, goes into llvm-9-dev, which doesn't provide the utils and,
thus, shouldn't have their exports declarations.

I guess we don't want to do two separate builds (one with
LLVM_INSTALL_UTILS for llvm-9-tools and one without for llvm-9-dev). Two
alternative fixes I could imagine:

(1) Keep LLVM_INSTALL_UTILS and remove yaml-bench from
_IMPORT_CHECK_TARGETS. It looks like we do this already for Polly and
sancov here:

(2) Remove LLVM_INSTALL_UTILS and copy the utils to the install-tree (or
package destination) manually.

With that I think we could revert these two changes:

What do you think?



More information about the llvm-dev mailing list