Removing LLVM testing tools from the install distribution

Project Infrastructure LLVM Dev List Archives
1

Should the binaries included in an LLVM release be generally useful to a wide audience of toolchain users, or is it OK to ship tools that are only really useful for LLVM development?

If the former is the case, can we consider not shipping tools which are exclusively for testing the compiler? E.g removing these 5 binaries from 5.0.2-rc1 would have saved over a hundred megabytes in uncompressed space for macOS users:

Binary name | Size in megabytes

2

I personally have no objections to removing the tools you just pointed
out, as long as important testing tools are kept around (in
particular, opt, llc).

Thanks,

3

Please keep llvm-symbolizer in the install distribution.

If a user’s program crashes then I like to print out a backtrace with file name/line number if compiled with debug. Forking off llvm-symbolizer is the easiest way for me to obtain the debug information.

Thanks.

4

A new one was just added recently - Clang’s diagtool. So if you’re looking at how to reduce install size, might want to double check that the motivation for adding that is consistent with/not contradictory with your goals/motivations for removing these.

(also since several of these are clang binaries/tools - maybe check with the cfe-dev list too)

5

A new one was just added recently - Clang’s diagtool. So if you’re looking at how to reduce install size, might want to double check that the motivation for adding that is consistent with/not contradictory with your goals/motivations for removing these.

Yep, the motivation for including clang’s diagtool seemed sound to me (i.e I can imagine diagtool being useful to a wide audience).

Actually, that change is what motivated me to take a closer look at what exactly makes it into our installs.

(also since several of these are clang binaries/tools - maybe check with the cfe-dev list too)

  • cfe-dev

vedant

6

Please keep llvm-symbolizer in the install distribution.

If a user’s program crashes then I like to print out a backtrace with file name/line number if compiled with debug. Forking off llvm-symbolizer is the easiest way for me to obtain the debug information.

Yep, at this point I’m only considering removing tools which are strictly for compiler testing.

vedant

7

I'd like to argue in the other direction for the windows distribution, basic tools like llvm-symbolizer are missing there, and it would be great if it was included.

--Ray