On Thu, Nov 29, 2001 at 01:15:03PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > I'm just pointing out that we'll end up with somelike really long and
> > ugly since there'll be at least 3 'defaults' and probably more. If you
> > think it's better to have lots of the test ? a : b's nested instead of
> > making these things architecutre-specific, that's fine I suppose.
>
> It's a tradeoff. The alternative to a long, ugly declaration in one place
> would be a bunch of marginally shorter and less ugly declarations scattered
> to hellandgone through the ruleset. :-)
Well, in arch/$(ARCH)/rules.cml or so.
> I know that the second alternative would be harder to compile and
> validate.
I don't know. How is it harder to validate
choice kernel_format_PPC
VMLINUX ZIMAGE ZNETBOOT
default ZIMAGE
choice kernel_format_ix86
VMLINUX ZIMAGE BZIMAGE BZDISK
default BZIMAGE
Than:
choice kernel_format
VMLINUX ZIMAGE BZIMAGE ZNETBOOT
defeult ((X86) : BZIMAGE ? ((IA64 or SPARC) ? VMLINUZ : ZIMAGE))
unless X86 suppress BZIMAGE
unless PPC suppress ZNETBOOT
> I judge that it would also be a net loss for humans
> maintaining the code -- too hard to be sure that you know what all
> the relevant declarations are. Better the big ugly declaration you
> know than the many smll declarations you know not...
Er, but this is an arch-specific question. The humans maintaining it
would be the maintainer for that arch, who really should know what's
relevant. There's also less of a chance of someone goofying up and
accidently forgetting to add unless MYARCH suppress FOOBOOTIMAGE that
they just added.
> There's a problem like this now with unless/suppress declarations, but
> I saw no way to avoid it there.
I guess I didn't read the other posts thourghly enough, what's the exact
problem?
> --
> <a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
>
> What is a magician but a practicing theorist?
> -- Obi-Wan Kenobi, 'Return of the Jedi'
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
