Keith Owens <[EMAIL PROTECTED]>:
> Only one of the menus will be visible, but the rule compiler does not
> know that. This is the problem for which the solution was to change
> choice to dynamically pick a default. I don't like that solution for
> two reasons :-
>
> (1) The overall help text for the choice is fixed, I cannot provide
> different hints for each architecture. Which means I cannot tell
> sparc users about milo, x86 users about lilo or grub etc.
>
> (2) It leads to horrible expressions like
>
> unless (X86 or (ALPHA or (SPARC32 or (SPARC64 or (MIPS32 or (MIPS64 or (PPC or
>(M68K or (ARM or (SUPERH or (IA64 or (PARISC or (S390 or (S390X or CRIS))))))))))))))
>suppress VMLINUZ
>
> That is worst case, but all it takes is one arch that does not
> support a particular boot format and we need expressions like that.
> The expression must be repeated for each boot format that is not
> universally available. Every new architecture has to find and
> change these rules.
>
> You can see why I wanted per architecture choices instead of one big
> choice with conditions. Is there any way of getting there? One
> possibility is to allow symbols to occur more than once as long as they
> are guarded, including being on menus that are completely suppressed.
> The rule back end refuses any input that makes the symbol visible in
> two places at once. IOW, delay the check for duplicate use of a symbol
> until the visibility data is known. Duplicate definition is always an error,
> duplicate use is only an error if the symbol is visible more than once.
OK. That might be a nice idea, but the symbols-occur-in-one-place-only
assumption is wired *deep* into the code for me to want to mess with it
when it's not at all hard to write rules with equivalent properties.
The right answer looks like this:
-------------------------------------------------------------------------
symbols
kernel_format_x86 'The format used for the installed kernel' text
All kernel builds create vmlinux as an ELF object. vmlinux may not be
suitable for loading, either because the bootloader cannot handle ELF
or the object is too large. This option selects the format for the
installed kernel. If unsure, use bzImage.
.
unless X86 suppress kernel_format_x86
private VMLINUX_X86 VMLINUZ_X86 BZIMAGE_X86 ZIMAGE_X86
choices kernel_format_x86 # The format that the kernel is to be compiled in
VMLINUX_X86 VMLINUZ_X86 BZIMAGE_X86 ZIMAGE_X86 default BZIMAGE_X86
menu installation
kernel_format_x86
=== arch/ia64/boot/rules-2.5.cml.
symbols
kernel_format_ia64 'The format used for the installed kernel' text
All kernel builds create vmlinux as an ELF object. vmlinux may not be
suitable for loading, either because the bootloader cannot handle ELF
or the object is too large. This option selects the format for the
installed kernel. If unsure, use vmlinuz.
.
unless IA64 suppress kernel_format_ia64
private VMLINUX_IA64 VMLINUZ_IA64
choices kernel_format_ia64 # The format that the kernel is to be compiled in
VMLINUX_IA64 VMLINUZ_IA64 default VMLINUZ_IA64
menu installation
kernel_format_ia64
# Here's where we pull everything together into
# architecture-independent symbols...
derive VMLINUX from VMLINUX_X86 or VMLINUX_IA64
derive VMLINUZ from VMLINUZ_Z86 or VMLINUZ_IA64
derive BZIMAGE from BZIMAGE_X86
derive ZIMAGE from ZIMAGE_X86
-------------------------------------------------------------------------
This way, you get to have your architecture-dependent help symbols and your
across-architecture build symbols both, *and* you make the relationships
explicit. The `private' declaration prevents your internal symbols from
being written to the config.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
Militias, when properly formed, are in fact the people themselves and
include all men capable of bearing arms. [...] To preserve liberty it is
essential that the whole body of the people always possess arms and be
taught alike, especially when young, how to use them.
-- Senator Richard Henry Lee, 1788, on "militia" in the 2nd Amendment
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
