Ben Collins-Sussman wrote:
> On May 11, 2005, at 9:52 PM, Scott Palmer wrote:
>
>> To be honest I find the entire process of "./configure" utterly
>> ridiculous.
>
> Perhaps you don't remember what the world was like before autoconf
> existed? Eek.
I do. It was a lot simpler. Things tended to fail in minor ways out of
the box that were trivial to fix and forward the fix on to the maintainers.
Now some things build easily, but generally only the mature ones.
Configuration takes longer than compilation. And errors mean most
developers are stuck against a huge learning curve that very few ever
surmount.
>> For example: It checks for things like stdlib.h - if you have a C
>> compiler that doesn't have this file you have much bigger problems
>> than compiling subversion. It checks for fortran compilers - why?
>> subversion is written in C. I could go on, but the point is that
>> the massive amount of "checking" just goes to show that there is
>> something so fundamentally wrong with the entire process that it
>> just makes me sad.
>
> Fundamentally wrong? autoconf solves the problem of portability
> better than anyone could have possibly dreamed of 20 years ago.
No, it doesn't. I dreamed of and built a superior system. So did a
number of other people.
> There's a reason it's the "standard'.
Oh? And what reason is that? The popularity of the GNU suite which
usually carries the load of autoconf as a necessary evil?
> Is it pleasant? No. Does it greet you in the morning with french
> toast, the daily paper, and a smile? No. Does it alleviate
> tremendous portability pain? Absolutely.
No, it doesn't. It alleviates some minor portability nuisances at a
huge cost in complexity. Moderate portability issues become major
portability issues. And major portability issues become insurmountable.
There are also an entire category of easy portability issues that
autoconf doesn't address at all, choosing instead to throw up it's hands
and demand that the user state something, in spite of the fact that easy
and obvious defaults exist.
Autoconf was never a good solution. It was a so-so solution whose
shortcomings were covered by enthusiastic maintainers. It is grossly
showing it's cracks now, even for simple and mature things like the
older gnu packages. The GNU standard "configure" interface was
basically a fine idea, (skipping the --host --target problems rms never
seemed to understand), but autoconf always has been and continues to be
a huge overhead by comparison to the alternatives. For tested software,
it's just flat out wrong.
--rich
ps, 1.2 fails for me on mac also.
------ making all in apr
Making all in strings
make[3]: Nothing to be done for `local-all'.
Making all in passwd
make[3]: Nothing to be done for `local-all'.
Making all in tables
make[3]: Nothing to be done for `local-all'.
Making all in file_io/unix
make[3]: Nothing to be done for `local-all'.
Making all in network_io/unix
make[3]: Nothing to be done for `local-all'.
Making all in threadproc/unix
make[3]: Nothing to be done for `local-all'.
Making all in misc/unix
make[3]: Nothing to be done for `local-all'.
Making all in locks/unix
make[3]: Nothing to be done for `local-all'.
Making all in time/unix
make[3]: Nothing to be done for `local-all'.
Making all in mmap/unix
make[3]: Nothing to be done for `local-all'.
Making all in shmem/unix
make[3]: Nothing to be done for `local-all'.
Making all in user/unix
make[3]: Nothing to be done for `local-all'.
Making all in memory/unix
make[3]: Nothing to be done for `local-all'.
Making all in atomic/unix
make[3]: Nothing to be done for `local-all'.
Making all in poll/unix
make[3]: Nothing to be done for `local-all'.
Making all in support/unix
make[3]: Nothing to be done for `local-all'.
Making all in dso/unix
make[3]: Nothing to be done for `local-all'.
/bin/sh /Users/rich/gnu/src/subversion-mac2/apr/libtool --silent --mode=link gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I./include -I/Users/rich/gnu/src/subversion-1.2.0-rc4/apr/./include -I../include -I/Users/rich/gnu/src/subversion-1.2.0-rc4/apr/../include -version-info 9:6:9 -o libapr-0.la -rpath /Users/rich/gnu/lib strings/apr_cpystrn.lo strings/apr_fnmatch.lo strings/apr_snprintf.lo strings/apr_strings.lo strings/apr_strnatcmp.lo strings/apr_strtok.lo passwd/apr_getpass.lo tables/apr_hash.lo tables/apr_tables.lo file_io/unix/copy.lo file_io/unix/dir.lo file_io/unix/fileacc.lo file_io/unix/filedup.lo file_io/unix/filepath.lo file_io/unix/filepath_util.lo file_io/unix/filestat.lo file_io/unix/flock.lo file_io/unix/fullrw.lo file_io/unix/mktemp.lo file_io/unix/open.lo file_io/unix/pipe.lo file_io/unix/readwrite.lo file_io/unix/seek.lo file_io/unix/tempdir.lo network_io/unix/inet_ntop.lo network_io/unix/inet_pton.lo network_io/unix/sendrecv.lo network_io/unix/sockaddr.lo network_io/unix/sockets.lo network_io/unix/sockopt.lo threadproc/unix/proc.lo threadproc/unix/procsup.lo threadproc/unix/signals.lo threadproc/unix/thread.lo threadproc/unix/threadpriv.lo misc/unix/charset.lo misc/unix/env.lo misc/unix/errorcodes.lo misc/unix/getopt.lo misc/unix/otherchild.lo misc/unix/rand.lo misc/unix/start.lo misc/unix/version.lo locks/unix/global_mutex.lo locks/unix/proc_mutex.lo locks/unix/thread_cond.lo locks/unix/thread_mutex.lo locks/unix/thread_rwlock.lo time/unix/time.lo time/unix/timestr.lo mmap/unix/common.lo mmap/unix/mmap.lo shmem/unix/shm.lo user/unix/groupinfo.lo user/unix/userinfo.lo memory/unix/apr_pools.lo atomic/unix/apr_atomic.lo poll/unix/poll.lo poll/unix/pollacc.lo support/unix/waitio.lo dso/unix/dso.lo -lresolv -lpthread
/usr/bin/libtool: for architecture: cputype (16777234) cpusubtype (0) file: -lpthread is not an object file (not allowed in a library)
/usr/bin/libtool: for architecture: cputype (16777234) cpusubtype (0) file: -lSystem is not an object file (not allowed in a library)
make[2]: *** [libapr-0.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [external-all] Error 1
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 18 00:04:17 2005