llvm dev - Dec 2019 - llvm-9-dev apt package missing yaml-bench

On 02/12/2019 15:21, Sylvestre Ledru wrote:
> yaml-bench is shipping in libclang-common-9-dev
Ok possible. Though, it adds an unnecessary 46MB to my docker image.
> 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.
Where can we review the build process for the apt packages?

On 02/12/2019 15:21, Sylvestre Ledru wrote:
> Hello,
>
> Le 02/12/2019 à 15:14, Stefan Gränitz a écrit :
>> Hello everyone
>>
>> I was just porting a project to build against the LLVM 9 apt packages
>> and noticed that the issue I filed and explained during the release
>> phase in https://llvm.org/PR43035 still persists:
>>
>> CMake Error at /usr/lib/llvm-9/lib/cmake/llvm/LLVMExports.cmake:1323
>> (message):
>>
>>    The imported target "yaml-bench" references the file
>>
>>       "/usr/lib/llvm-9/bin/yaml-bench"
>>
>>    but this file does not exist.
>>
>> Here's a minimal repro:
>>
https://travis-ci.org/weliveindetail/apt-llvm-9-dev-repro/builds/619590445#L204
>>
>>
>> Is anyone else seeing this too? Is there an obvious fix that I
don't
>> see? What's your workarounds?
> yaml-bench is shipping in libclang-common-9-dev
>
> It should be indeed in llvm-9-dev instead.
>
> Could you please open a bug in
> https://bugs.llvm.org/enter_bug.cgi?product=Packaging ?
>
> Thanks
> Sylvestre
-- 
https://flowcrypt.com/pub/stefan.graenitz at gmail.com

Le 03/12/2019 à 23:03, Stefan Gränitz a écrit :
> On 02/12/2019 15:21, Sylvestre Ledru wrote:
>
>> yaml-bench is shipping in libclang-common-9-dev
> Ok possible. Though, it adds an unnecessary 46MB to my docker image.
Yeah, this would be a temporary workaround.
>> 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?

I already made the change:

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/132a99b7a0db3771f2ec0cd4d9598a98fc25750f
> Where can we review the build process for the apt packages?
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/tree/9/

(change branch if you want a different version)

Cheers

S

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

IMHO the underlying problem is that we pass LLVM_INSTALL_UTILS here:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/9/debian/rules#L363

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:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/9/debian/rules#L649

(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:
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/cb79a639f54880bfe46167ea332210f3e3aac1a4
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/132a99b7a0db3771f2ec0cd4d9598a98fc25750f

What do you think?

Cheers
Stefan

-- 
https://flowcrypt.com/pub/stefan.graenitz at gmail.com