[1380] in Kerberos_V5_Development
build system redesign ideas
daemon@ATHENA.MIT.EDU (Tom Yu)
Fri Jul 12 21:42:54 1996
Date: Fri, 12 Jul 1996 21:42:50 -0400
To: krbdev@MIT.EDU
From: Tom Yu <tlyu@MIT.EDU>
The current build system in our source tree is very unwieldy to
maintain. It is full of kludges which may not continue to work in the
future. I suggest a partial rewrite of our build system after Beta 7
is released. Below, I have tried to summarize the main goals and
constraints that apply to this task.
GOALS:
* Separate the functions of configuration and Makefile generation,
i.e. generating paramaterized Makefile rules out of configure.in is
rather confusing because it's not obvious from the Makefile that many
rules are being inserted via the configure script.
* Use as few configure scripts as possible in the source tree. This
will result in the configuration process taking much less time. Right
now, on the DEC Alpha on my desk, this takes almost half an hour,
which is almost the same as the time required to compile everything.
CONSTRAINTS:
* The autoconf system seems to be designed primarily for the sake of
configuration, with very little effort towards complex Makefile
generation. This is a feature of Imake that is sorely lacking in our
current build system. The AC_PUSH_MAKEFILE macros that we currently
have in our aclocal.m4 file achieve the sort of paramaterized Makefile
rules generation that Imake does, but with considerable penalties in
complexity and maintainability, in addition to putting Makefile rules
generation into a file that should be reserved for configuration
purposes.
* It is not possible to use a single configure script for the entire
source tree because some libraries and programs require different
preprocessor symbols to be defined, and also because source files that
may need compilation to replace missing library functions
(AC_REPLACE_FUNCS) differ from directory to directory.
* The use of gmake is not recommended because of requirements on the
Windows and Mac builds. In addition, the paramaterized recursive
expansion feature added by OV is not in the main gmake source yet.
Also, some sites may be reluctant to use gmake.
* Several of the above constraints further restrict the build process
to building one library per directory. This may require moving source
files around.
%%%%%%%%%%
Coments? Anything else that may be relevant?
---Tom
