Leisner.Henr@xerox.com (Marty) (04/04/89)
I need (for a long time) a better way to produce multiple configurations on multiple targets from a single set of sources. What I'm doing now is running makefile's through the C preprocessor and ifdefing things like CC, CFLAGS, AS, etc. I'm working on a sun386i -- I'm currently have SunOS make (looks better than older makes I've used), gnu make and cake. I'm not sure how much I like cake -- it seems a little too different for my tastes. I want a single master makefile for each project. I'm currently running shell scripts to preprocessor the makefile prior to running make. I guess I'm going to put the different objects/outputs in different subdirectories (so make won't get confused), but I'll still preprocess the makefiles. I'm looking for useful ideas/strategies for managing this problem (the fact that on the sun386i I'm also cross-compiling via dos based C compilers even adds to the confusion). If there's interest I'll summarize and post the replies. thanks, marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
scs@adam.pika.mit.edu (Steve Summit) (04/09/89)
In article <18927@adm.BRL.MIL> Leisner.Henr@xerox.com (Marty) writes: >I need (for a long time) a better way to produce multiple configurations on >multiple targets from a single set of sources. >...I guess >I'm going to put the different objects/outputs in different subdirectories >(so make won't get confused), but I'll still preprocess the makefiles. One thing I've found which helps is if your C compiler(s) pay attention to the -o flag even in the presence of -c. (4.3bsd may have introduced this.) Then you can you can use a different suffix (not just .o) for each kind of object file, and keep them all in the same directory with one copy of the source. I've used .ovax for vax, .o11 for pdp11, .po for profiled, etc. The Makefile contains new default rules like .SUFFIXES: .po .c.po: $(CC) $(CFLAGS) -p -c -o $@ $*.c Someday I'll post my retargetable C compiler driver which allows the use of -o in this way, and allows easy selection of compiler back-ends to make cross-compilation easy. Steve Summit scs@adam.pika.mit.edu
tbray@watsol.waterloo.edu (Tim Bray) (04/09/89)
In article <10445@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >One thing I've found which helps is if your C compiler(s) pay >attention to the -o flag even in the presence of -c. >Then you can you can use a different >suffix (not just .o) for each kind of object file, and keep them >all in the same directory with one copy of the source. I've used >.ovax for vax, .o11 for pdp11, .po for profiled, etc. An excellent idea, but you happen to be in the Sun world, and you're running Sunos 4.x, and you do this, you get hundreds of brain-dead idiotic warnings from cc about 'file with unknown suffix .po passed to ld'; not that it doesn't work. I mean, *I* know what the file is, *unix* knows what the file is by looking at the magic number, which ld BETTER DO ANYHOW, on Unix we gotta depend on file extensions to tell us what a file is?, gotta wonder what kind of underworked enthusiast at Sun put that inspiration in. Grumble, Tim Bray, New OED Project, U of Waterloo, Ontario
mlandau@bbn.com (Matt Landau) (04/10/89)
In comp.unix.wizards (<13157@watdragon.waterloo.edu>), Tim Bray writes: >depend on file extensions to tell us what a file is?, gotta wonder what kind >of underworked enthusiast at Sun put that inspiration in. Probably the same bozo who added the warning "Include of /usr/include/... is non-portable" every time you #include a file whose name begins with '/'. Yes, thank you, Mr. C Compiler. We know it's unportable. That's why the first step in bootstrapping our source code on a new machine is to auto-generate all those include lines correctly for the environments in use. (Yes, we have good reasons for doing that.) But thank you very much for the warning, Mr. C Compiler. Now, please tell me how to turn the goddamn thing off!! What, no compiler flag to suppress this warning? Not even in 4.0.1?? Thanks. Thanks a lot. Looks like it's time to replace /bin/cc with a shell script that pipes that compiler output through grep -v (again). *Sigh* Why don't people THINK before they implement? -- Matt Landau "Sheep are very dim." mlandau@bbn.com
aad@stpstn.UUCP (Anthony A. Datri) (04/11/89)
In article <10445@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >In article <18927@adm.BRL.MIL> Leisner.Henr@xerox.com (Marty) writes: >>I need (for a long time) a better way to produce multiple configurations on >>multiple targets from a single set of sources. I like the way X 11.3 does it -- you have one tree of sources, and for each make you create a tree of links into it. Common sources, seperate binaries. Combine this with the standard #ifdef's and such, and you've got a workable system. Of course, I'm still trying to figure out how X figures out what kind of machine you're making it on. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, my VT05, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
guy@auspex.auspex.com (Guy Harris) (04/11/89)
>Probably the same bozo who added the warning "Include of /usr/include/... >is non-portable" every time you #include a file whose name begins with '/'. Nope. "/lib/compile" was developed by somebody at Sun; the warning in question was developed by somebody at AT&T, as part of S5R3.
jfc@athena.mit.edu (John F Carr) (04/11/89)
There is a program at Athena called "machtype" which tells you what kind
of machine you are on (and other trivia, like CPU type and display hardware,
if you care). This is also a shell variable, "hosttype", in our version of
tcsh. I put in my .login "setenv HOSTTYPE $hosttype", and make other
programs depend on this (those that I can't modify the source for with
#ifdef <machine type>).
Such a program is extremely useful when using NFS, since there is otherwise
no convenient way of determining what hardware you are running on. In
particular, $PATH must be set to point to the correct bin directories on
NFS filesystems exported to multiple machine types. Our naming convention
is to add the machine type as a prefix to "bin", so we have "vaxbin" and
"rtbin" subdirectories of most exported filesystems (as well as "vaxlib" and
"rtlib" if appropriate). The Andrew File System has built in support for
machine type, being able to substitute it automatically in a filename (but
as a suffix -- we managed to choose opposite conventions).
Solutions I have heard to the multiple target machines types include:
1. Create lots of symlinks. Run make in the correct directory and it
will do the right thing.
2. Have disctinct make targets per machine type. So, to compile for
the RT one runs "make rt"; for a vax "make vax".
3. Use an environment variable, modify make to define a variable,
or otherwise get it to notice the machine type. Like (2) except
make makes the distinction between target machine types, instead
of the programmer.
Now if only we can get X to distinguish between a 16" and a 19" display...
--
John Carr "When they turn the pages of history,
jfc@Athena.mit.edu When these days have passed long ago,
bloom-beacon! Will they read of us with sadness
athena.mit.edu!jfc For the seeds that we let grow?" --Neil Peartarosen@hawk.ulowell.edu (MFHorn) (04/11/89)
> >>I need (for a long time) a better way to produce multiple configurations on > >>multiple targets from a single set of sources. > > I like the way X 11.3 does it -- you have one tree of sources, and for each > make you create a tree of links into it. Tcsh added two environment variables, HOST and HOSTTYPE. HOST is your hostname, HOSTTYPE is compile-time configurable. I like the idea, but to be really useful, it has to become part of configuration files and part of the filesystem. I should be able to put into a makefile a line like prog: prog.c prog.h cc prog.c -o $HOSTTYPE/prog All programs that use some sort of configuration file (inetd, syslog, sendmail) would need to recognize $ENVIRONMENT to be really useful. lrwx------ 1 arosen 9 Jan 1 00:00 bin -> bin/$HOSTTYPE [for this, you could "set path = ( ~/bin/$HOSTTYPE $path )"] lrwx------ 1 arosen 19 Jan 1 00:00 .Xdefaults -> $DISPLAY/.Xdefaults lrwx------ 1 arosen 14 Jan 1 00:00 .history -> $HOST/.history All that's needed is an efficient way for the kernel to get at a process' environment variables. Yeah, I know ATT has also suggested environment variables be incorporated into path names, but I came up with the idea on my own before I heard about it. Honest. I just would've had a little more trouble getting the idea in print. -- Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should've been
chris@mimsy.UUCP (Chris Torek) (04/12/89)
4.3BSD-tahoe introduced a `#define' in <machine/machparam.h> called
MACHINE; on the VAX it is
#define MACHINE "vax"
and on the Tahoe it is
#define MACHINE "tahoe"
The program /bin/machine is made from the source (slightly trimmed)
#include <sys/machine.h>
main()
{
puts(MACHINE);
exit(0);
}
and thus produces `vax', `tahoe', or whatever.
make(1) has a built-in macro ${MACHINE} which expands to whatever
make's source got out of <machine/machparam.h>, so Makefiles can
read
# Makefile for /usr/src/etc
...
SUBDIR= ... etc.${MACHINE}
all: ${PROGS} ${SUBDIR} ...
${SUBDIR}: FRC
cd $@; make ${MFLAGS}
In addition, make reads the file `.depend' as well as the file
`Makefile' (or `makefile'), so that automatic dependency genration need
not rewrite makefiles. This is much nicer (and clearly the way it
should have been done originally).
Existing `make's can be made to do the same thing by superimposing a
front-end shell script. Here is /usr/local/bin/make from our Suns.
(`machine' is found in /usr/local/bin and says `echo sun'. This points
up a problem: `sun' is not always specific enough; some sources might
be Sun-2 specific and some might be Sun-3 specific. A simple fix would
be to make it produce `sun2' or `sun3' and make bin.sun2 and bin.sun3
symlinks to bin.sun in /usr/src/local/bin; but it might be better to
have two levels, or perhaps more.)
#! /bin/sh
if [ -f .depend ]; then
if [ -f makefile ]; then
f="-f makefile -f .depend"
else
f="-f Makefile -f .depend"
fi
for i do
case "$i" in -f*) f=;; esac
done
else
f=
fi
exec /bin/make $f ${1+"$@"} MACHINE=${MACHINE-`machine`}
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chrisallbery@ncoast.ORG (Brandon S. Allbery) (04/15/89)
As quoted from <13157@watdragon.waterloo.edu> by tbray@watsol.waterloo.edu (Tim Bray): +--------------- | In article <10445@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: | >One thing I've found which helps is if your C compiler(s) pay | >attention to the -o flag even in the presence of -c. | | An excellent idea, but you happen to be in the Sun world, and you're running | Sunos 4.x, and you do this, you get hundreds of brain-dead idiotic warnings | from cc about 'file with unknown suffix .po passed to ld'; not that it doesn't +--------------- Sounds familiar... ncoast does this. Since when is Sun importing System *III* misfeatures?! (I haven't seen System V pull this stunt.) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser