Hi Scott!
On Thu, 12 May 2005, Scott Palmer wrote:
> On May 11, 2005, at 11:10 PM, 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've been programming since the mid 80's and thankfully I never had
> to deal with what you imply was a worse mess. I suspect perhaps the
> problem is mostly with unix.
Well, what did YOU have to deal with then?
And no, the problem is not limited to Unix, porting software from one
version of Winblows to another can be a nightmare as well (if Microsoft
simply changed some APIs)...
Another reason why autoconf exists is to *standardize* these checks. Before
the existence of autoconf, each programmer either wrote his own checks, or
worse, simply omitted them for the sake of making assumptions.
Unfortunately, in quite a few cases, these assumptions didn't prove to be
true...
> >> 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.
The reason for this is basically that the configure shell script includes a
set of standard checks when it was initially created by running "autoscan".
This tool creates a configure.scan file which includes these standard checks
in the correct order. Later on, configure.scan is renamed to configure.in,
further checks (m4 macros usually starting with AC_) are added by the
developer(s) and then autoconf is run in order to actually create the
configure shell script that performs these checks when it is invoked.
> Yes. It's ludicrous, pathetically so. What part of checking for
> fortran 77 to compile 'C' do you find reasonable?
You're right that not all of the checks performed are reasonable for the
particular case of compiling Subversion, BUT see my statement above :-)
> When I run ./configure I shake my head and wonder "what were they
> thinking?"
Should be a bit more obvious from what I said above.
> Just what went so bad that THIS was considered the
> solution?
Yes, because it's a *standardized* solution.
> It's not so much that the solution is "fundamentally
> wrong", it's the situation that leads to such a solution.
Well the situation regarding portability of software was much worse at the
time when autoconf was created. Things have become better now with the POSIX
standard, but there are still some differences between the BSD and SYSV
flavors of Unix.
Apart from that, note that there are also checks for 3rd party packages,
which are quite useful when compiling Subversion.
> A C compiler is a prerequisite for compiling C code - brilliant..
Yep. Bear in mind that
/1/ C compilers can be named differently from system to system (dependent on
which implementation is installed). For instance, a C compiler can be
named cc but it can also be named xlc (AIX C compiler).
/2/ There can be more than one implementation of a C compiler installed on a
particular system (gcc in addition to implementation provided by the
vendor)
> let's write a tool that takes forever to scan my system (in two
> stages ./autogen.sh and ./configure) to see if I have one, rather
> than simply running 'make' and seeing it complain if I don't. ;-) I
> can get the error message from autoconf after watching it go through
> a ton of useless stuff, or I can get the error message instantly from
> 'make'.
Ah, you're saying that making the programmer messing around with makefiles
is better than having a correct one automatically generated for you (in case
you pass the right option to configure)?
> Strangely enough on my Mac 'cc' invokes the C complier, like it does
> on every unix-ish system I've ever seen. What problem is autoconf
> solving for me again?
See above.
> What is fundamentally wrong is that autoconf is needed at all.
Right, but blame the different Unix vendors. Furthermore, each developer has
the freedom to install Berkeley DB by compiling it by himself or use the
implementation shipped with his Linux/BSD/whatever distribution. autoconf
provides support for such cases.
> I'm obviously missing the bit that makes any of this a sane process.
Hope it all is a bit clearer now...
> And I'm quite happy to remain ignorant :-)
You seriously consider this a good attitude???
Kind regards,
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 13 10:35:44 2005