Jeff Garzik wrote:
>
> Another option for pcmcia module-naming compatibility is to simply
>
> cp 3c59x.o pcmcia/3c575_cb.o
>
aargh. I'm screwed.
- The consensus here seems to be that I should continue to generate
drivers/net/3c59x.o as well as drivers/net/pcmcia/3c575_cb.o. Fair
enough.
- I don't want to copy a single .o file into two places because the
source _should_ be compiled twice. The pcmcia Makefile could at some
point in the future pass additional #defines into the compiler via -D,
for example which may trigger conditional compilation. (In fact, it
defines -DPCMCIA for _some_ targets today. But not all. Bug?)
- I don't want to put a special target in the pcmcia/Makefile because
this becomes a maintenance headache. Plus it needs duplication of all
the stuff which generates .3c575_cb.o.flags.
- The cleanest way of doing this is to make pcmcia/3c575_cb.c a
one-liner:
#include "../3c59x.c".
But mkdep doesn't recur! It only tracks the first-level inclusions, so
pcmcia/.depend says:
3c575_cb.o: 3c575_cb.c \
../3c59x.c
3c589_cs.o: 3c589_cs.c \
This is very, very naughty of mkdep.
I'll do the cut-n-paste from Rules.make into pcmcia/Makefile for the
while.
Really, mkdep should be taught to recur. This probably explains why a
good old 'make clean' sometimes makes wierd things stop happening.
-- -akpm-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:18 EST