> Some people, when they have a problem, say "I know, I'll use autoconf".
>
> Now they have two problems.
I'll be a little more specific on this one.
1. Autoconf is unmanageable
Autoconf is a mess of m4 scripts. Nobody knows m4, and nobody
understands the scripts.
M4, the language that makes PHP look clean.
2. Autoconf is nondeterministic
The results of autoconf depend on the exact packages installed on the
user's system. With autoconf, you are never quite sure how your
software was installed -- which makes it impossible to obtain repeatable
bug reports.
An extreme example, on a Debian system, Emacs will use different
techniques for sending mail depending on whether the Exim4 package was
installed when the Emacs package was being compiled.
3. Autoconf is useless
Autoconf was designed at the time when we had the whole mess inherited
from the Unix wars -- at the time, we had USL Unices (SIII, SVR3, SVR4),
BSD Unices (4.2BSD, 4.3BSD) and hybrid systems (such as SunOS). Writing
portable C code was much more difficult than today.
Nowadays, all systems comply with some dialect of POSIX. Most of the
time, C code is easily made portable by checking for the optional
features of POSIX. The only remaining difficulty is tweaking the
makefiles, which I believe is the duty of the downstream packager.
Juliusz
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Polipo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/polipo-users
