On Wed, Sep 22, 2004 at 11:44:30PM -0500, Rob Browning wrote: > For those that don't know, stalin is very demanding on the build host. > It consists of one 22MB C file, so it does take a *very* long time to > build on older architectures. Accordingly, I try to be careful to not > upload new versions very frequently. That's one honking great source file. I don't suppose that splitting it into lots of little files would be a possibility? My guess is that the source file is auto-generated in some way, but it seems like that would be one way of reducing the demands somewhat (I imagine that GCC would chew incredible amounts of memory trying to compile and optimize a source file of that size). Perhaps even some sort of auto-split file might work -- one function per file or something, and a big .h file with all of the function prototypes #included at the top of each. Again, possibly not practical, but I figure impractical suggestions are better than none. > While I'm not very inclined to agree that the size of the source is a > release critical bug, Not as such, no. However, an inability to build on an architecture is a FTBFS bug, which is typically RC. It appears, though, that it's more of an autobuilder limitation than anything (finite RAM and run time, and a need to process other packages sometime before the heat death of the universe) than a true fail-to-build on an architecture. Could you perhaps build on non-autobuilder machines for those slower arches and make new Debian releases that way? > especially since we've already been providing > packages for those architectures. I am willing to consider dropping > support for slower architectures if that's the "right thing to do". Does the package do useful things on those slower arches once compiled? (Practical performance-wise, mostly) If so, I don't think that removing support for those architectures is a winner. - Matt
Attachment:
signature.asc
Description: Digital signature