Greg Banks <[EMAIL PROTECTED]>:
> Wouldn't it be simpler to allow the rules file to not specify
> a `default'? The runtime semantics of this would be that the first
> unsuppressed choice is displayed as the default. So Keith could
> write:
>
> choices kernel_format # The format that the kerne
"Eric S. Raymond" wrote:
>
> John Cowan has proposed allowing the default expression in a choice to be
> a string-valued derive that must be the name of a choice. This kind of
> type punning makes me cringe, and anyway it would be hard to check at compile
> time that the returned string is ne
> Suppose we have split declarations for derivations or defaults of
> symbols that are shared across architectures. It would then be
> locally convenient for configuration maintainers to move these
> declarations from the top-level rules.cml file piecemeal to rules
> files in different arch subt
On Thu, Nov 29, 2001 at 02:48:50PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > On Thu, Nov 29, 2001 at 02:20:05PM -0500, Eric S. Raymond wrote:
> > > Tom Rini <[EMAIL PROTECTED]>:
> > > > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> > > > arch/$(ARCH)/
Tom Rini <[EMAIL PROTECTED]>:
> On Thu, Nov 29, 2001 at 02:20:05PM -0500, Eric S. Raymond wrote:
> > Tom Rini <[EMAIL PROTECTED]>:
> > > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> > > arch/$(ARCH)/boot/rules.cml ?
> >
> > Nothing. But if they aren't single declarations,
On Thu, Nov 29, 2001 at 02:20:05PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> > arch/$(ARCH)/boot/rules.cml ?
>
> Nothing. But if they aren't single declarations, what's going to
> *keep* them there?
Wha
Tom Rini <[EMAIL PROTECTED]>:
> Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> arch/$(ARCH)/boot/rules.cml ?
Nothing. But if they aren't single declarations, what's going to
*keep* them there?
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
Question with
On Thu, Nov 29, 2001 at 02:06:40PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > > Information distributed through the ruleset in such a way that it's hard
> > > to know all the places a given symbol participates.
> >
> > On the compiler side of things or the human side of thi
Eric S. Raymond wrote:
> Information distributed through the ruleset in such a way that it's hard
> to know all the places a given symbol participates.
But that's what xref tools are made for. In the kernel, the directory
(or even the file) is the unit of ownership. I argue that stuff like
t
Tom Rini <[EMAIL PROTECTED]>:
> > Information distributed through the ruleset in such a way that it's hard
> > to know all the places a given symbol participates.
>
> On the compiler side of things or the human side of things?
It's the human side I'm primarily worried about.
> All of the rule f
On Thu, Nov 29, 2001 at 01:30:27PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > 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
Tom Rini <[EMAIL PROTECTED]>:
> 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 ZI
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
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
On Thu, Nov 29, 2001 at 12:53:42PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote:
> >
> > > I think I may have a better idea. Let the default be a ? : name-valued
> > > expression. So your format choice could l
Tom Rini <[EMAIL PROTECTED]>:
> On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote:
>
> > I think I may have a better idea. Let the default be a ? : name-valued
> > expression. So your format choice could look something like this:
> >
> > choices kernel_format
> > VMLINUX VML
On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote:
> I think I may have a better idea. Let the default be a ? : name-valued
> expression. So your format choice could look something like this:
>
> choices kernel_format
> VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE
> default
Keith Owens <[EMAIL PROTECTED]>:
> >Ugh. That's nasty. Can you imagine a change in the spec language that
> >would make this unnecessary?
>
> The problem is the default which needs to vary from one arch to
> another. i386 defaults to bzImage, ia64 to vmlinuz etc. The default
> choice for one
On Thu, 29 Nov 2001 02:46:38 -0500,
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>Keith Owens <[EMAIL PROTECTED]>:
>> I am having some problems with the kernel format option, every arch
>> needs this option but the choice list and default will vary between
>> architectures. I am slowly coming to
Keith Owens <[EMAIL PROTECTED]>:
> In my never ending quest to try something stupid:
>
> choices kernel_format # The format that the kernel is to be compiled in
> VMLINUX VMLINUZ BZIMAGE ZIMAGE default BZIMAGE
>
> unless IA64 suppress VMLINUZ BZIMAGE ZIMAGE
>
> Will set BZIMAGE because
In my never ending quest to try something stupid:
choices kernel_format # The format that the kernel is to be compiled in
VMLINUX VMLINUZ BZIMAGE ZIMAGE default BZIMAGE
unless IA64 suppress VMLINUZ BZIMAGE ZIMAGE
Will set BZIMAGE because it is the default, even though it has been
suppre
21 matches
Mail list logo