[1680] in Kerberos_V5_Development
Re: something useful
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Aug 30 18:46:42 1996
Date: Fri, 30 Aug 1996 18:46:37 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Raeburn <raeburn@cygnus.com>
Cc: Kev <klmitch@MIT.EDU>, krbdev@MIT.EDU
In-Reply-To: Ken Raeburn's message of 30 Aug 1996 17:01:25 -0400,
<tx1bufs8u3e.fsf@cygnus.com>
From: Ken Raeburn <raeburn@cygnus.com>
Date: 30 Aug 1996 17:01:25 -0400
Sounds like you're getting into an area that should perhaps be covered
by automake instead of autoconf. For the short term, your version
will probably work okay, but for the longer term you should take it up
with the autoconf and automake maintainers.
To quote from the automake info manual:
Sometimes `automake' isn't enough. Then you just lose.
Given that we need to handle shared library generation in a clean and
consistent fashion, and I doubt automake will be doing so anytime in the
near fashion --- the only sane thing that I can think of is to be able
to do parameterized macro expansion in the Makefile.in.
When you are building a shared library, the actual files which must be
generated, and (as a result) the dependencies for building a shared
library, differ from platform to platform. As a result, it's impossible
to perform this using the typical autoconf hack of playing games with
Makefile macros. So instead, I asked Kevin if he could come up with a
way of doing parameterized macro expansion in autoconf.
If we hide this information inside a parameterized macro expansion which
differs from platform to platform (or based on some feature test,
although the mind boggles about how one would do feature tests that
would allow us to support shared libraries), it should make life much
simpler.
The other alternatives that have been proposed for solving this problem
are:
1) Putting in gmake-specific constructs into the Makefile
(which will break the Window platform, and cause other
compatibility headaches). Besides, I believe it's against the
GNU coding standards to require gmake.
2) From the makefile.in, put in a constrct of the form:
make -f $(top_srcdir)/lib/@SHLIB_MAGIC@ <arg1> <arg2>
Where <arg1>, <arg2>, etc would be things like the shared
library name, the objects, etc.
I had assumed that there was general agreement that if we could do
simple macro substitution (i.e., one level, fixed number of arguments)
in autoconf, it would be far superior than any of the above solutions.
If anyone wants to convince me that automake will *ever* be featureful
enough to handle the krb5 source tree, they're certain willing to try
convincing me of that fact. (Better yet, they can deliver a fully
functional automake. :-)
- Ted
