On Friday 08 August 2003 15:56, Raphael Manfredi wrote: > I'm so fed up that after the 0.92.1 release, due this week-end if > everything goes fine, I've decided to kiss good bye to the autocrap tools > and move back to a much more ancient configuration system known as > "metaconfig". Unlike autocrap, it works and is self-contained. It's also > backward compatible and new versions are not expected to introduce > breakage. As a matter of fact, there have been no revisions of metaconfig > since 1997... :-)
Wait a second, is that why your name sounds familiar? Wasn't metaconfig written by someone named Raphael Manfredi? I tried to use metaconfig back in the late 80's to port some BSD code to AT&T, gave up, and did it all by hand. I assume it's gotten better since then? Also, didn't Larry Wall fork off from the main branch a decade ago or so and make the perl configurator out of metaconfig? They still use that, don't they? Are we using the perl version? Otherwise, where do we get it? Are packages available for RPM-based distros? > Since we all hate autocrap tools, it's time to finally act. Sure, we'll > need a few units for the detection of GTK/Glib/libxml2 and so on, but that > should not be too bad. Which means the gtk-g team will essentially be taking over maintenance of metaconfig, I guess? (Of course if my memory is on track and it's your package, that shouldn't be too surprising.) > We'll also miss the options like "--enable-nls" or > "--enable-gtk2". Instead, we'll have questions asked, or cryptic defines > to give to the command line. It has to be usable non-interactively, otherwise you can't do the config inside rpmbuild. It would be cool if the user had a choice, of course--specify it all on the command-line and force metaconfig to try to guess the rest, or let it ask the user to confirm everything. (I haven't rebuilt perl in a long time, but doesn't it have basically these two options?) As for cryptic stuff on the command line, is something like "-Denable_nls" that much more cryptic than "--enable-nls"? As long as there's something equivalent to ./configure --help to let the user know what the choices are (or if configuring interactively tells the user which command-line options would repeat the exact same build or something), it doesn't really matter what the options look like. Also, keep in mind that we need to be able to pass in (to either metaconfig or the makefile or configure script or whatever it generates) things like where the datafiles go, where everything gets installed, etc.; otherwise building RPMs will be a major pain. > [In case you haven't figured by now, I'm fed up with autocrap]. Well, it's no worse than make.... Maybe we should ditch both auto* and make and do everything in cons or something better? ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
