[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How should stalin be handled on slower architectures?

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

Reply to: