|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Fri, 14 Jun 1996 14:16:44 -0400 From: "Theodore Y. Ts'o" <tytso@MIT.EDU> To: Tom Yu <tlyu@MIT.EDU> Cc: krbdev@MIT.EDU In-Reply-To: Tom Yu's message of Thu, 13 Jun 1996 21:20:49 -0400, <199606140120.VAA28004@dragons-lair.MIT.EDU> Well, what's the advantage of *not* consildating them more? I can only think of two. The first reason for *not* consildating them all into one top-level package is that we know there are some packages that we will want to distribute as stand-alone packages in the future: util/et util/ss (maybe --- if it deserves to live at all; it's main advantage is that tcl is **huge**.) util/pty appl/bsd/telnet The second reason for not consildating everything into one top-level package is that it means that any change to the configure.in will force a *large* number of configure substitutions. However, we have that problem even worse today when we modify aclocal.m4, and we seem to deal. Is there any other reason for further breaking down which directories have their own configure.in? 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. - Ted
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |