[1819] in Kerberos_V5_Development
make vs. gmake and the Athena source tree
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Sep 29 16:53:15 1996
Date: Sun, 29 Sep 1996 16:53:01 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: krbdev@MIT.EDU
Cc:
(For people who don't know me, I'm the Athena release engineer.)
Recently, there's been a lot of argument over whether Kerberos 5
should try to simplify its build system by requiring gmake. Sam,
Marc, and proven in particular have come out in favor of the idea.
One of these days I'm going to have to put Kerberos 5 in the Athena
source tree and use it for real, and requiring gmake for the sake of
one renegade package, especially one coming from people who work on
the same floor as me, seems like a big loss. So, let me address the
reasons to use gmake that I've heard of:
* In several places you have to edit multiple lists of files
whenever a new source file is added. This gets worse if you
want to start generating .o, .po, and .so files from a .c
file; you could wind up with four or more different places
to add a file. It would be convenient to have just one
list--say, $(SRCS), and then have OBJS=$(SRCS:.c=.o) and so
forth.
It turns out that POSIX.2 specifies these kinds of
substitution rules, and both Solaris 2.4 and IRIX 5.3
implement them (as does pmake). From a release engineering
perspective, I have no problem with Kerberos 5 using this
make feature.
(That said, I still think it would be a strategically bad
move to start using suffix substitutions. If all four lists
are right next to each other in a Makefile, it's unlikely
that they will get out of sync, so all you're doing is
saving yourselves a small amount of effort at the expense of
making life harder for anyone who wants to build Kerberos.)
* If Makefiles could include the boilerplate Makefile code
with an include directive, then you wouldn't have to
regenerate Makefiles after editing the boilerplates.
It turns out that "include" is a relatively common make
feature, but pmake does not implement it (pmake has
.include instead), and it is not specified by POSIX.2.
There are other occasions when you have to regenerate
Makefiles, so I don't see the lack of include as a
systematic obstacle to maintaining the build system.
Note that configure cannot try to work around the lack of
"include" in a vendor make, because configure has no idea
which make program you are going to use.
* Building a single library from sources organized in multiple
directory is a bit tough without VPATH. I treat this as a
"Doctor, Doctor..." complaint: if you think about it hard
enough, you'll find that your build system gets a bit hairy
even if you do assume VPATH, and that it was a mistake to
create subdirectories to categorize source code rather than
to identify targets. There are other libraries out there
with more than 250 functions, and they generally keep them
all in the same directory.
Anyway, it still isn't all that much hair to deal with the
problem without VPATH; you can do what you're doing now, or
you can do what the BSD 4.3 libc did and create intermediate
.a files whose objects are later extracted into a temporary
directory and rebuilt into the actual library.
* At least one developer has complained that no one can tell
him what the least common denominator vendor make is. If
you conform to the POSIX.2 make specification and test your
Makefiles with the Solaris 5.3 and IRIX 5.3 vendor make,
then I'll be satisfied from a release engineering
perspective.
