Testing cml2 1.9.9, kbuild 2.5, 2.4.16-ia64-011214.
"config.out", line 267: bad token `SCSI_DEBUG_QUEUES' while expecting symbol.
Stock 2.4.16 defines SCSI_DEBUG_QUEUES, it is used in
drivers/scsi/scsi_merge.c. SCSI_DEBUG_QUEUES should be in cml2.
"config.out", line 313: bad token `SCSI_QLOGIC_QLA2100' while expecting symbol.
New option in the ia64 patch.
"config.out", line 522: bad token `AGP_I460' while expecting symbol.
Not sure if that is a new option or an old one come back to haunt us.
The ia64 patch reinstates the drm 4.0 code that Linus threw out, drm
4.1 does not completely work on ia64 yet.
"config.out", line 666: bad token `EFI_PARTITION' while expecting symbol.
New option in the ia64 patch.
"config.out", line 667: bad token `DEVFS_GUID' while expecting symbol.
New option in the ia64 patch.
What is the best way in CML2 of handling arch specific patches that add
options?
File load violated these constraints:
(SMP implies (X86 or (PPC or (ALPHA_SABLE or (ALPHA_RAWHIDE or (ALPHA_DP264 or
(ALPHA_WILDFIRE or (ALPHA_TITAN or (ALPHA_GENERIC or (SPARC32 or (MIPS64 or
ARCH_S390)))))))))))
IA64 is missing from the SMP list,easily fixed.
I am trying to do something that I suspect CML2 was not designed to
handle.
=== arch/i386/boot/rules-2.5.cml
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
choices kernel_format_x86 # The format that the kernel is to be compiled in
VMLINUX VMLINUZ BZIMAGE ZIMAGE default BZIMAGE
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
choices kernel_format_ia64 # The format that the kernel is to be compiled in
VMLINUX VMLINUZ default VMLINUZ
menu installation
kernel_format_ia64
Compiling rules, please wait...
"arch/ia64/boot/rules-2.5.cml", line 8: symbol VMLINUX occurs in another menu
(kernel_format_x86)
"arch/ia64/boot/rules-2.5.cml", line 8: symbol VMLINUZ occurs in another menu
(kernel_format_x86)
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.
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
