[1322] in Kerberos_V5_Development
Re: sub-packages of krb5 for autoconf purposes
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Sat Jun 15 01:15:56 1996
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Tom Yu <tlyu@MIT.EDU>, krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 14 Jun 1996 22:15:28 -0700
In-Reply-To: "Theodore Y. Ts'o"'s message of Fri, 14 Jun 1996 14:16:44 -0400
"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> Is there any other reason for further breaking down which directories
> have their own configure.in?
In order to avoid linking programs against inappropriate libraries,
we'd have to set a bunch of different make variables, and pick and
choose those we want for each application (e.g., AIX "-ls" would only
be needed in one or two places). Similarly for any uses of
AC_REPLACE_FUNCS and @LIBOBJS@. Which means porting to a new system
is more likely to require changing Makefile.in as well as configure.in
if some needed function is off in some library on the new system.
The usual autoconf way is to build up LIBS and substitute for @LIBS@
in Makefile.in, but common autoconf usage has never stopped the
Kerberos team from doing things differently before... :-)
> One detail we need to be sure we get right is that the rules that
> automatically run config.status to generate a new Makefile when either
> Makefile.in or config.status has changed will need to modified to deal
> with the fact that config.status will no longer necessarily be in the
> current directory.
I think that's already taken care of.
