Path: utzoo!attcan!uunet!gistdev!flint
From: flint@gistdev.gist.com (Flint Pellett)
Newsgroups: comp.software-eng
Subject: Re: Anyone know of a "better" 'make' than vanilla System-V's?.
Message-ID: <1015@gistdev.gist.com>
Date: 3 Oct 90 15:31:56 GMT
References: <1990Oct3.000440.5275@hades.ausonics.oz.au>
Organization: Global Information Systems Technology Inc., Savoy, IL
Lines: 54

greyham@hades.ausonics.oz.au (Greyham Stoney) writes:

>My company is working on a medium-to-large software project for which we use
>standard System-V 'make' to specify the rules by which objects are made from
>source files, and for specifying the source file dependancies.

>There are some problems with this however, which lead me to ask if there is
>anything better we could use; In particular, 'make' seems to have the following
>annoying problems & deficencies:

>* The Makefile is assumed to reside in the current directory and each Makefile
>	must contain the rules saying how to make objects, since make's
>	built-in rules aren't right. We have well over 100 Makefiles in
>	one project; most of which contain basically the same information; but
>	with minor differences. Eg: they all contain the same command to put
>	an object in a library, although the library name differs. Changing the
>	name of the librarian utility (if we needed to) would be impossible
>	(have to change 100+ Makefiles just to do that).

You can "include" other files into your makefile to handle this: just put
all the stuff that every makefile uses into a makefile.h someplace, and
then add this line into all the makefiles:

include /wherever/makefile.h

(Note: it is not a #include, as that would be a comment.)  Appropriate
use of environment variables in the .h file, (like to contain the library
name in your example) should allow your one .h file to handle a lot of
the overhead in the other makefiles.  Deciding what to put in this .h
is something you need to think over carefully though.

>* Dependancies must be explicitly listed in the Makefile; and they are never
>	kept up to date: No ammount of forcing people is going to keep them up
>	to date, and it's a pretty pointless exercise anyway. In order to
>	control the rules with which our objects are made, we delta Makefiles
>	which makes it even worse since to update the depenancies you have to
>	get the thing for editing. Why can't the dependancies be discerned
>	from the source file at make time?.

I've always though that at least something of this level should be possible.
At the very least, figuring out what .h files a file depends upon, by
scanning it for #include commands, could be done at make time.  But you
wouldn't want make to always do that, because it would slow down the
process too much.  (Maybe an option to test dependancies, and then
optionally add them into the makefile when it finds missing ones, would
be a good addition.)  Unfortunately, I don't know of anything that does
this right now- the closest things are things that will create a makefile
for you by figuring out the dependancies, and those are pretty much
worthless when you already have a complex makefile existing.

-- 
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL  61874     (217) 352-1165
uunet!gistdev!flint or flint@gistdev.gist.com