>--[Murphy]--<[EMAIL PROTECTED]> > > What do you dislike about it? It's just a configuration system. > Indeed. I hope we aren't afraid to try something different.
The problem is not that it is different, but that it's bad. autoconf standard doesn't just mean that people are used to create the configure script with autoconf; people are used to the autoconf configure's syntax (in fact, there are configure scripts not or not completely build by autoconf; Apache 1.3 is an example, mplayer reinventing the wheel another). The syntax of the metaconf generated Configure has a) a different name b) uses completely different calling syntax. autoconf's syntax is well known. metaconfig's is not. The credo of autoconf is also different than metaconfig. autoconf allows the user to give all it's options when calling configure; it is non-interactive. metaconfig, however, is meant to be interactive. While it may be fun to watch watch the Configure script running and asking questions for half an hour the first time, it won't be after the umteenth time. It's also inherently unreproducible, because a slight change of what you've entered might result in completely different results. In opposite, autoconf saves its command line in it's config.status/config.log (allowing automatic re-running of configure using automake), even saving influential environment variables. Even worse, though metaconfig is created to be interactive, the gtk-gnutella README etc. all tell the user to run it non-interactively - this discrepancy shows quite clear the underlying structural weakness. Just watch metaconfig's Configure run non-interactively: from it's output you'll never know what it would have asked, because random parts of its lengthy output are not printed. It's simply not up to this task when you want to do something reproducable. > Those who have seen where Raphael has taken gtkg will have no trouble > believing he can do interesting things with metaconfig. I'm not doubting Raphaels programming skills. I am, however, doubting his knowledge in regards to cross-compiling or portable programming, thus I doubt metaconfig will be used in any other new project (It's used by Perl only because it has always been used as Perl is older than autoconf; and for a complex project as Perl it is non-trivial to switch. Just see how long Apache has taken). > There's nothing sacred about autoconf. It's been quite popular for about > 5 years and the standard for perhaps 3, No, it isn't. If you'd come up with something better, I'd wager everyone would use it. Of course, "bette" includes it to understand at least the syntax autoconf uses, and to include at least the features autoconf does - cross compiling, building outside of the source dir, working on even the most obscure platforms. It's just that the problem autoconf solves is incredible hard in the general case. autoconf has come a long way. automake is coming a long way as well. Catching up to that is nothing that can be done in a few week's work. > http://freshmeat.net/articles/view/889/ Look, I've read this rant. Several times. It is essentially just that: a rant of someone who never read any manuals, nor actually used the tools he complains about. Some facts he gets wrong: * the user doesn't need autoconf to run configure (actually the most basic fact that you simply can't get wrong) * if you autoreconf with an too old version than the script requires, the error message is quite obvious * the meaning of --with-X vs --enable-X is well-defined * configure doesn't use a cache file by default * using autoconf doesn't require any knowledge of m4 * the autotools do have adequate documentation (the autobook) He also blames autoconf for bugs in the configure.ac someone wrote (like not detecting the right include dir - though as a user you should just add the right directory to CFLAGS and be done with it) or irrelevant things (the size of a generated Makefile and/or configure script is irrelevant as you're not supposed to edit it - if he had read the first two lines he would have known which file it was generated from). There are valid critics for autoconf and for automake; none of them, however, are mentioned in that rant. And most complaints about the autotools are about badly written configure.ac. > Who knows, perhaps metaconfig will be the standard in another five years > and we can mock the kids who complain about it, "Ha, when I was your age, > all we had was Autoconf! Yep, I remember having many discussions about > metaconfig with ram, himself, back in the day." You may be right that there might be another standard some time in the future. It won't be metaconfig. metaconfig is a generation older than autoconf, and it shows. Just let it rest, and let the writing of configure systems to people knowledgable in that area. -- 100 DM = 51 � 13 �. 100 � = 195 DM 58 pf. mailto:[EMAIL PROTECTED] http://www.ruediger-kuhlmann.de/ ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
