> Let them install BASH and get out of our way.As someone else pointed out, bash uses autoconf. Also, while its good to talk about bringing up GNU environments on top of proprietary ones, the long term view is to also think about bringing them up on raw iron. So, pick a small set of prerequisite tools (bash might or might not be one), and factor the bootstrapping of those tools into a separate project. Make that a separate problem, then design the build tools to take advantage of its having been solved. Another issue (related in my warped way of looking at things) is all the compilation of configure/build scripts. It causes an infinite supply of inefficiencies, confusions, and little annoyances to have to compile configure.in and Makefile.am -- and with a fixed set of modern prereqs in place, that can easily be fixed. While adding shell functions, get rid of m4 and use a modern make (but don't screw the bootstrapping of the prereq tools). Finally, I still wish that a side-effect of the libtool effort was a document/database that explained clearly and concisely how to deal with shared libraries in various environments. As it stands, that information is weaved into convoluted code and the situation is glossed over with "trust us -- we're building the right abstractions". -t _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
