Re: CFO: Why ./configure?

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

  • Next message: VBDis: "Re: CFO: Why ./configure?" 
    Date: 15 Sep 2003 02:55:22 GMT

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

    >Ad a)
    >Thus, even though I might know that on some IRIX versions I must include
    ><bstring.h> to get a memcpy, others might not. That's a kind of idea
    >autoconf can handle for you: It "imports knowledge" of the build process
    >into your own tools. Let others help you here with their knowledge.

    That's what I mean with "Scheuklappen", most Unix people only can see
    complicated solutions, as used throughout their whole environment. [Sie sehen
    halt einfach den Wald vor lauter Bäumen nicht mehr. Vielleicht kann's ja jemand
    übersetzen ;-] My simple solution, for the above example, would make references
    to specific header files obsolete, and remove the source of such trouble.

    >Thus, whereas autoconf surely introduces more possible errors - nobody
    >is perfect - it can handle more problem cases than you could by hand.

    That's a good idea, making people work together, and providing methods for
    distributing their knowledge. But there exists a significant difference between
    distributing knowlegde (algorithms) and distributing workarounds (procedures).
    Knowledge can be distributed and applied in various ways, whereas concrete
    workarounds and related tools are restricted, in both their implementation and
    use, to certain specific environments. You see the difference?

    >Ad b)
    >"complicate" or "simplify" is a matter of taste, and what you're used for.

    I see many concrete factors, which can express the simplicity or complexity of
    a solution. Of course the scope of such considerations can vary, so that the
    autoconf people will find the invention and use of a new language "simpler"
    than using existing languages. But when we consider autoconf, or any other
    autotool, as part of the overall build process, then the introduction of a new
    tool, and a new language, certainly complicates things. Micro-optimization,
    regardless of whether applied to code, tools, or other procedures, usually
    turns out as introducing only trouble, as soon as any of the implicitly assumed
    conditions changes. Global optimization instead will allow to remove many parts
    of a program or process, so that no micro-optimization is required for
    non-existing things. That's why I consider the build process as a whole, and
    everything what can be removed from any of its components will simplify things.

    >Ad c)
    [drunk - later]

    DoDi

  • Next message: VBDis: "Re: CFO: Why ./configure?"

    Relevant Pages

    • Re: use of backward single quote in procedure names
      ... BASIC interpreter is somehow part of every machine. ... distributing a program written in BASIC implies distributing only the ... never being able to extend the language. ...
      (comp.sys.acorn.programmer)
    • Re: Python vs. Lisp -- please explain
      ... Speed, ease of programming, necessity to learn/use a secondary ... language, issues with distributing, portability. ...
      (comp.lang.python)
    • How widespread is Framework 1.1.4322?
      ... will be multiple language Versions. ... The app will be about 1 MB, it will be distributed via download. ... What are you experiences with distributing the .Net Framework? ...
      (microsoft.public.dotnet.general)