m5@lynx.UUCP (Mike McNally) (11/15/88)
In some makefiles we have here we use a slightly demented but reasonably effective method for keeping multiple executable versions of the same program in one directory. Each version is compiled for a different target platform. Object files for the UNIX host version are called blah.u.o, those for another version are called blah.s.o, and those for a third type are called blah.t.o. Therefore I have .SUFFIXES lines that look like this: .SUFFIXES: .u.o .t.o .s.o and implied translation things that look like this: .c.u.o: $(uCC) -c $*.c mv $*.o $*.u.o .c.t.o: $(tCC) -c $*.c mv $*.o $*.t.o .c.s.o: $(sCC) -c $*.c mv $*.o $*.s.o This setup works fine on my Integrated Solutions 4.2BSD machine, and on our own OS using our own "make". Over the weekend, I tried to move some code to a Sun 3/110 we have here and I noticed that the Sun "make" just didn't work. In ultra debug mode, it just indicated that it couldn't find anything like "l,.u.o" in its rules, so it quit. I presume that the version of the OS on the Sun is relatively recent; the "make" executable seems to be dated 88/02/07 if some strings sucked out of it are correct. Note that comments regarding my admittedly brain-damaged "make" technique will be appreciated, but are not responsive; I'm curious about any rules I might be breaking. If someone could try this on a System V machine I'd be interested. -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go.
shankar@hpclscu.HP.COM (Shankar Unni) (11/16/88)
> > .SUFFIXES: .u.o .t.o .s.o > > and implied translation things that look like this: > > .c.u.o: > $(uCC) -c $*.c > mv $*.o $*.u.o Pretty close. "ld" is not too picky about the suffix of its input files. Make, on the other hand, often gets confused by stuff like the one above: it keys off the "."'s. Try .SUFFIXES: .uo .to .so .c.uo: $(uCC) -c $*.c mv $*.o $*.uo ... --- Shankar.