Holger Rauch wrote:
> 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)
There is no need for autotools for this. A sane make tool knows $(CC) and if
you want to change that you can set it in the environment - which also works
with configure, but to the extent that it is fixed after the configure call,
so you don't have to make the same settings for compiling in a different
shell.
> > 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)?
A properly written makefile doesn't define anything like CC=gcc or other
similar atrocities. At most it supplements the existing settings.
> > 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.
Just as a well written makefile does with CPPFLAGS and LDFLAGS.
All this said, I use autotools for every non-trivial project because of its
dependency tracking, easy creation and installation of programs and
libraries, aforementioned saved configuration vs having to set them on every
compilation, having different configurations in different build dirs and the
checks it performs on the system. Yes, there is some serious pain involved
seeing which is also what the original ranter was annoyed by, but in the end
it's not so bad - in fact quite a few times some sensible checks did help me
getting things up and running quicker than if I had not had them.
Oh, btw: be happy that you don't have to mess with autotools integration,
Scott, that is where The Real Pain(tm) is. ;)
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 13 11:32:41 2005