Re: Why ./configure?
From: Mithaz (abinayshunyashynyaek_at_yahoo.com)
Date: 09/01/03
- Next message: F Brown: "Email Test"
- Previous message: Erik Max Francis: "Re: CFO: Why ./configure?"
- In reply to: VBDis: "CFO: Why ./configure?"
- Next in thread: Ulrich Eckhardt: "Re: CFO: Why ./configure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 31 Aug 2003 20:32:26 -0500
"VBDis" <vbdis@aol.com> wrote in message
news:20030831211146.11891.00000383@mb-m11.aol.com...
> I'm not very well off these days, and my systems aren't either. Or can you
tell
> me why configure tells me "your compiler cannot create executable files"?
My
> gcc knows how to create executables, I know that my gcc can do so, only
> configure disagrees. And when I remove that obsolete test from the
configure
> script, everything works fine. But it was not easy to find the according
lines
> in configure, between those many thousand(!) other lines :-(
>
> But this is only one exceptionally ridiculous example, what nonsense is
done
> and produced by configure. In almost every tested GNU project configure
> prevents me from proceding, due to some condition which was not preseen by
the
> author of the configure script, maybe human or automake or any other tool.
>
> So my question to everybody is:
>
> Why is it impossible to distribute GNU projects with all the files, which
are
> required to compile and link the program? What's the special task of
configure,
> which can not be accomplished in any other way?
>
>
> IMO configure and many other parts of a project are obsolete. A project
can and
> should be shipped with immediately usable source files, regardless of the
> target platform and other conditions, which the author can not anticipate.
Even
> if this sounds incredible to you, please let me explain may thoughts, so
that
> you can point me to the places where my assumptions are wrong.
>
> Let's assume an dumb author, which only knows about his own system, so
that his
> project will build and work only on his specific system. Let's furthermore
> assume an guru, which can make that project build and work on a different
> system, which is unknown to the author. Obviously that guru can implement
his
> solution only, when he has access to all the files, which are required to
> compile and link the project. Consequently it's inacceptable if any
failure in
> the preceding step in the build process will result in missing source or
header
> files. Otherwise the whole project can not be considered to be portable,
if
> nobody but the original author can add support for other targets. Okay?
>
> Now let's wrap up the whole build process from the end, so that we can
find out
> what must and can be done in the preceding steps. In the last step the
linker
> creates a runnable program, with no unresolved external references. Having
> reached this step we have to face several conditions:
>
> - everything is fine - done! :-)
> - some library is missing - install and retry.
> - no such library is available - back up to the preceding step.
>
> The preceding step in this case is the compilation. Even if the library,
as
> used by the author, is not available on the target system, there may exist
a
> workaround. When such a workaround exists, then it can be added to the
source
> code, and the compiler has to be instructed by some condition (#define),
which
> of multiple solutions to choose on this special target system. But every
such
> workaround is not really restricted to a single target system, instead
it's
> applicable to every system on which the replacement library can be
installed.
> So the condition really has to reflect the state of the target system,
> resulting from the installation of some library. Such conditions need no
> complicated guessing by a stupid configuration tool, instead it's
sufficient to
> #define the according symbol when the library is installed. All what a
> configure tool or script can do is a check of the existing configuration
file,
> with appropriate messages when a required feature is not already
installed, and
> no workaround is known so far.
>
> This procedure also allows for cross-building projects, when every target
> system is represented by the target specific libraries (for the linker),
and
> the according configuration and header files (for the compiler). All these
> files can be kept in distinct target specific directories, as already in
use
> for gcc. Only that the informations in these directories now are not only
used
> by gcc, instead all target specific tools and scripts also reside there,
so
> that the whole build process only needs to know which of these directories
to
> use. Then also an equivalent of the current Makefile.am is sufficient for
> building every project, besides for very special cases like building OS
kernels
> and related modules or bootstrapping compilers.
>
>
> Now please tell me what's wrong with this simple model.
>
> DoDi
sorry, dont have a direct answer to your question, but want to make a point.
People who have had taken a class under prof Sol.. in UIC, like me, will
reiterate his words as explained in class :-
"Simple dosen't mean it's easy ; One problem has a very complicated solution
which few understand.
One takes that problem, investigates it, ponders, reasons, delibrates and
comes up with a solution which is simple.
The irony here is someone else comes and looks at the problem and declares,
'Ah, that's easy' "
I feel your pain. Wish C/C++ had a simple compile/link model as java. But
again have gotten used to carrying the burden of legacy.
-- AB
- Next message: F Brown: "Email Test"
- Previous message: Erik Max Francis: "Re: CFO: Why ./configure?"
- In reply to: VBDis: "CFO: Why ./configure?"
- Next in thread: Ulrich Eckhardt: "Re: CFO: Why ./configure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
