Ludovic Courtès writes: >> - either move the libs to a "lib" output, >> - or move the "bin" and "include" folder to a new output. >> >> The second approach has the benefit of being less disruptive for dependents. > > I have a slight preference for a “lib” output since that’s more in line > with what we do for other packages. OK. > Nice! I looked for something like this when I packaged > ‘clang-tools-extra’ and didn’t find it. This should go into the next > ‘staging’ branch (or ‘core-updates’?). I can send a patch for llvm-10, but I guess many llvm-dependents will have to be updated accordingly. I suppose that the input --8<---------------cut here---------------start------------->8--- ("llvm" ,llvm) --8<---------------cut here---------------end--------------->8--- will need to be turned to --8<---------------cut here---------------start------------->8--- ("llvm" ,llvm "lib") --8<---------------cut here---------------end--------------->8--- for most packages. I have no experience with LLVM, so can someone confirm that this is the right way to go? >> All in all, it looks like we can save 52 MiB out of 140 MiB from the LLVM >> package (and 210 MiB from its closure). > > That’d be great. To clarify the ambiguous sentence I wrote above, we would save 52 MiB from the closure size of LLVM. > An additional option would be to have a package with fewer backends by > default (currently all of them are enabled and that takes up quite some > space). In particular, Mesa doesn’t depend to depend on an LLVM variant > with 15 backends when it’s only going to use one. Are you suggesting an alternative or a tweak to add on top of my suggestion? Where would we store the different backends? In different outputs? On which backend does Mesa depend for instance? Cheers! -- Pierre Neidhardt https://ambrevar.xyz/