On Sun, 12 May 2002, Michael Brown wrote:
> I have modifed genrules.pl to produce pattern rules alongside the "normal"
> rules. The upshot is that it is now possible to type
> make bin32/PCI_NIC--ADDITIONAL_DRIVER.{rom,lzrom,etc.}
> for any combination of PCI_NIC and ADDITIONAL_DRIVER. No multi-driver
> ROMs will be built by default (i.e. "make" will produce only single-driver
> ROMs).
> <snip>
> The current multi-driver solution is not particularly elegant in its
> implementation and has three known bugs:
> <snip>
> 2) It only works for dual-driver Roms - there is no way of even specifying
> three or more drivers. This is irritatingly inelegant but not likely
> to cause practical problems; if you try to squeeze in three or more
> drivers then Etherboot will die horribly through RAM starvation anyway.
> It is probably possible to fix this using some of the more esoteric
> features of make - patsubst, wildcard etc.
This problem, at least, is fixed. You can now type, for example:
make bin32/dfe538--prism2_pci--tulip.rom
and it will happily generate a ROM with three drivers (rtl8139, prism2_pci
and tulip) with the dfe538's PCI IDs.
> 3) The Roms makefile is too long and could probably be shortened
> considerably by judicious use of pattern rules.
I'm less convinced of this now. I managed to reduce the config-*.o rule
down to a single pattern rule (which handles both PCI and ISA, single- and
multi-driver), but the others are problematic. The main issue is that
there doesn't seem to be any way to have the dependencies being a function
of the target (other than in the very simplistic pattern-rule style). As
an example:
rtl8139--%.img : bin32/rtl8139.o \
$(foreach driver,$(subst --, ,%),bin32/$(driver).o)
make rtl8139--prism2_pci--tulip.img
does NOT evaluate to the expected
rtl8139--prism2_pci--tulip.img : bin32/rtl8139.o \
bin32/prism2_pci.o bin32/tulip.o
because the function evaluation happens *before* the pattern matching on
the %. This means (I think) that any functions in the dependencies can
never know the contents of the "%".
As a workaround, I have made it so that building any multi-driver ROM is
dependent on all the *.o files (ugly).
If anyone knows a way to fix this, I'd really appreciate it.
Michael
|