I'm having the following snippet in LLVM currently: if is-flagq -g || is-flagq -ggdb; then ewarn "The C++ compiler -g option is known to increase the size of the package" ewarn "considerably. If you run out of space, please consider removing it." ewarn (( build_size *= 10 )) fi But I feel like that's more common issue and something that could be handled within the eclass.
How about adding CHECKREQS_MEMORY_DEBUG_BUILD CHECKREQS_DISK_BUILD_DEBUG_BUILD CHECKREQS_DISK_USR_DEBUG_BUILD CHECKREQS_DISK_VAR_DEBUG_BUILD and using them with use debug, instead of doing some abitrary calculation?
That looks like a solution for a very special case, and certainly there are other similar scenarios where space requirements will be variable, dependent on architecture, CC, CFLAGS, USE flags (think of multilib which may double diskspace), &c. Why don't we leave it to the ebuild to calculate things and assign the existing variables accordingly? The ebuild should know much better than a general eclass what its requirements are.
Just to be clear, the usual developer (like me) has *no clue* how big -g build is going to be? I've added *10 based on bug report there, I think.
(In reply to Michał Górny from comment #3) > Just to be clear, the usual developer (like me) has *no clue* how big -g > build is going to be? I've added *10 based on bug report there, I think. The factor won't be universal though, but will depend on the package, and times 10 looks like an extreme case. For example, with app-editors/emacs-24.5 I get a disk space requirement in /var of 420 MB without -ggdb, which increases to 478 MB (i.e. by some 14% only) with that option.
Maybe we could start by having portage output summary of disk space requirements in build log? Basically 'du -hs $WORKDIR' + combined size of installed files.
Portage is outputting space requirements now, and I don't think we need to do anything from the eclass directly. In case of specific packages like llvm, we can adjust the requirements from ebuild.
