Re: CFO: Why ./configure?

From: VBDis (vbdis_at_aol.com)
Date: 09/27/03

  • Next message: Ritesh Kumar: "Re: wait" 
    Date: 27 Sep 2003 19:21:44 GMT

    Im Artikel <bk4pgu$5ac$1@mamenchi.zrz.TU-Berlin.DE>, Thomas Richter
    <thor@cleopatra.math.tu-berlin.de> schreibt:

    >>>> 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? (-;

    Just a question: I always have to install packages in su mode. How do you do
    the same, without asking your administrator to do that for you?

    Why then shouldn't it be possible to use your workaround even for other things?

    >For the "user", yes. There's one procedure
    >
    >$ ./configure
    >$ make
    >$ make install
    >
    >That's it.

    Agreed, but when ./configure aborts with an error, the output of that procedure
    is NULL :-(

    >> 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.

    Autoconf is not a solution for the documented problems, only a workaround.

    >> 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.

    Please be honest. "autoconf" is for the programmer, not for the user of a
    package. Even if a user is not normally expected to modify a source package, he
    has to perform the same steps as a programmer takes, in order to build the
    package. An IDE can integrate everything, from unpacking a package until its
    installation.

    >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.

    Simply forget about the GUI when talking about an IDE. Some developers use
    Emacs as their IDE, from which they can reach all related information and
    tools.

    >> An IDE should be part of a specific system, not part of every package.

    >But all this *requires* that everyone agrees on the way the database is
    >setup. And that exactly *will not happen*.

    Why not? An agreement about the interface for an IDE already exists, at least
    it's implied in the current configure and make and other related tools,
    directory structures and files. Adding further tools and files does not require
    an explicit agreement, besides that they have to be available on the target
    system. I cannot see any significant difference, whether a package requires the
    installation of e.g. a new version of a library on the target system, or
    whether it requires the installation of another tool. Nobody has to agree how
    configure works, but everybody has to agree to use it, as it is. Consequently
    modifications of the internals require no further agreements.

    When configure currently stores all retrieved information in files, which are
    private to a package, then it should not be impossible to find locations for a
    permanent storage of all these informations, as far as these are not related
    only to a specific package. In a simple approach configure could look for such
    files in the directory from which it was invoked. Then it's up to the user to
    start configure from his dedicated system configuration directory. Configure
    itself then can notice the difference between the directories, and can create
    and maintain the persistent "databases" there. This is not really different
    from the current use of cache files by configure.

    DoDi

  • Next message: Ritesh Kumar: "Re: wait"
    • Quantcast