On Sat, Feb 22, 2003 at 09:22:38PM +0300, Yaroslav Rastrigin wrote: > Hi ! > Well, I was reading this thread with great attention, and there's my 2kopecks: > > > (determined from the configuration) and is compiled and linked with > > the same options that the main application will be compiled and linked > > with. When running make for the first time, a makefile rule will be > > invoked to build this test program. If it builds successfully, the > > build process continues. If there is an error, the build process > > interrupts. This would happen quite fast and wouldn't require the user > > to build the whole program before discovering that some library was > > missing or some option was not set. > Well, if you could link this test program with -lfreetype , it absolutely > doesn't means you'll get right version of freetype. autoconf was lately > somewhat great in determining right versions of needed libs and their > possibilities (not that I'm pro-autoconf, this thing still frustrates me as > an overly-bloated, especially with lots of (often unnecessary) redundancy ).
AFAIK, autoconf has two methods of determining version: 1. By checking if a specific function, specific header file, etc. exists. 2. By running "<package>-config --version". And perhaps more. In any case, the test is only seldom built into autoconf, it is often instead provided as an extension by a software package. Function and preprocessor checks could be inserted into the test program. Calling the -config script, however, would have to be done in the makefile or a script. > > > > When it comes to configuration, there could be three configuration > > files (system.mk-style). One with default settings, one with settings > > generated by a configure script (optional), and one that includes the > > first two and lets the user override settings from them. Thus the user > > does not have to use configure script at all, and even if the user > > chooses to do so, he or she can still override the determined > > settings. However, this requires the maintainer to keep all these > > files in sync, so it would probably be best to have a master file that > > these are generated from by the maintainer. > Complicated... Perhaps. Do you have a less complicated suggestion? > > > > After some more consideration, I kind of agree with you that it is > > better to not use autoconf at all, because autoconf is based on the m4 > > macro language. This is mainly for historical reasons, it would be > > better to use a real scripting language, even the autoconf manual says > > so. A replacement for autoconf based on a real language would be able > > to generate better configure scripts, and the input files would be > > easier to understand and more concise. > Nope. M4 is great for text processing and pattern substitution, and that's > what autoconf/automake primarily does. Well, maybe. I thought that perhaps the shell code generated would be of better quality if a real language was used. But maybe not. > Real scripting language - which one ? > Perl will be probably interesting idea, but with lots of strange hacks most > perl authors often do, such autoconf will became unmaintainable (or, at > least, unreadable) quite quickly. Probably, some lisp-based language would > do... I like Lisp, but too many people doesn't... I think. I don't like Perl. > Well, for ion, I don't see the need for autoconf/automake - they will not make > things better for the user, be it first-time compiler or power-user. > ./configure --help and > ./configure --prefix=/usr --with-xft=yes > isn't that much easier than > vi system.mk > For my personal taste, well-written Makefile with options in first lines (with > comments and all) is way better than configure opts, and I've edited too many > automake-produced Makefiles to get around some blind assumptions, spread all > over 120Kb Makefile... Don't confuse this with automake. I don't suggest generating makefiles. And well, I don't feel Ion needs this kind of checking either. I regard this mostly as a theoretical discussion, as some packages do need checking (IMO). Perhaps it's off-topic. > BTW, for perl-based Makefile generator - take a look at tmake, TrollTech's > system. Slightly QT-centric, but great tool if you need to quickly create > basic project's Makefiles and Options... Not very popular, though, but very > easy to learn... Ok. /Pelle
