Re: CFO: Why ./configure?

From: Thomas Richter (thor_at_cleopatra.math.tu-berlin.de)
Date: 09/15/03 

Date: 15 Sep 2003 16:31:26 GMT

Hi,

>>> wouldn't it be easier to create a header memory.h ( as a symlink or a
>>> copy of bstring.h ) to gain the compatibility?
>>
>>No, I'm not the administrator of the system. I can't do that.

> Then ask your administrator to do that for you.

That would help me, but not any other IRIX users that want to compile
my project. "Ask the Sysop to do it for you" is always a solution, but
Sysops have better things to do, you know? (-;

> Then the system wide solution
> can be used by every user, for every project. Your administrator also will be
> happy about procedures which are readily available for the system, so that he
> doesn't have to reinvent the wheel for every single problem.

Exactly, that's why autoconf can help you, instead of the SysOp.

>>Where's the X11 include I need?
>>Where's the ncurses include I need? How or why does this call trigger
>>makes in all the sub-directories? Where's the documentation created?
>>Where's the archive packed?

> All these also are questions for an administrator.

No. I don't want to pick up the phone or write a mail just to be able
to compile my program. The system can find out this better and simpler.

> He should specify the
> appropriate places, once and forever.

Thus, the "works fine for me" solution. Consider if I get a mail about
"your program doesn't compile on XYZ". What would happen if I had to answer
"ask your SysOp to fix it for you". That's not what users expect. The
program must find out, not the user.

> The currently used procedures are not easy to follow,

For the "user", yes. There's one procedure

$ ./configure
$ make
$ make install

That's it.

For the author: It's the same problem as ever: You need to learn something.
I can't help you learing C or C++ or Java, or... I afraid if you want to
supply a platform as diverse as *ix, then that's the price.

> Portability requires that all procedures are
> described in a more abstract way, which is understandable by the tools
> on every
> platform, and best also to the human reader, which may have to resolve
> remaining problems.

That has been done as much as possible. Go check the autoconf documentation,
it explains the problems and how to check for them.

> The autotools can be seen as a step towards an IDE, and the ideas behind these
> tools are not bad. But the implementation sucks :-(

What do you expect? An IDE is something completely different than autoconf,
and has different targets. autoconf resp. configure targets at the user.
An IDE targets at the programmer.

Besides, but that's a different topic, I find the IDEs I've seen too limited
for "real world problems". The Win VS IDE might be all very nice looking and
colorful (German: "ClickyBunty") but when it comes to real problems, then I've
a hard time finding the right button to press on. Make/autoconf is more
flexible, but harder to use. Well, it's the same old story again: An IDE
is user-friendly, but I need expert-friendly tools. The learning curve
is different. Whereas it is trivial to write a "hello world" or even a medium
sized program with an IDE, it gets nasty as soon as the project grows and
possibly requires interaction with different languages, different systems,
different setups... A typical makefile here builds not only the binary,
but also runs LaTeX, dvitops for building the documentation, runs zip to
build the distribution.... Try that with an IDE that is "as simple to use"
as make.

> An IDE should be part of a specific system, not part of every package. Such an
> IDE will provide all information about a software project, and will put all
> that information into the package. Then the IDE of the target system will use
> that information to build the package, in exactly the way which is appropriate
> for that target system. Then any assumptions or suspicions about the possible
> target platforms are obsolete, and must and should not become part of a
> distributed package.

But all this *requires* that everyone agrees on the way the database is
setup. And that exactly *will not happen*. *ix is, unlike Win32, not
developed by a central maintainer with monopolistic approaches. It is by
construction a diverse system with many providers.

So long,
        Thomas