Re: [Gnu-arch-users] Managing changes to projects that use autoconf/automake with tla

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Thu, 2004-04-08 at 11:04, Tom Lord wrote:

    >> That has _already_been_done_ for a subset of c/b/i tools.  For
    >> example, Python and Perl both have standard install processes
    >> defined by tools that ship with Python and Perl.

    > Yeah, but they can depend on Python or Perl.  These are much
    > better languages for writing c/b/i tools than POSIX make and
    > POSIX shell, which are the least common denominator among Unix
    > systems.

    > I don't see how you could create fundamentally better tools
    > without giving up on make and sh.  And once you do that, you're
    > not solving the same problem that autoconf/automake are.

The essense of a c/b/i tool is that it implements a very high level
language and a standard library in that language which programmers
then use to write c/b/i rules.   So, for example, the VHLL in autoconf
is the language you use to write "configure.in" files ---- that VHLL
being implemented in m4.

C/b/i tools must satisfy the constraint that programs in their VHLL
are directly executable on target systems and cross-compilation hosts.

There are three strategies available for satisfying that constraint:

1) Implement the c/b/i language using only "standard" tools that are
   certain to be available on all target systems.  I don't know of any
   serious c/b/i systems that do this because the available standard
   tools are too weak.  Package-framework comes _close_ to this but
   isn't quite this since it depends on GNU make.

2) Implement the c/b/i language as a compiler that emits code which
   can be directly executed on all target systems.   This is what
   auto* -- it compiles auto* programs to generic sh and make code.
   If auto* did not depend on GNU m4 and on a largish library of
   macro definitions which is not normally shipped with programs, 
   then it could be in class (1).

3) Implement the c/b/i language as a compiler or interpreter, making
   sure that the language implementation itself is easy to bootstrap
   on all target systems.  The first step of the c/b/i process on a
   target system is thus to make sure that the c/b/i language
   implementation has been built.  This is the approach taken by the
   X11 build system with imake.  (This is also the category that
   package-framework is really in, GNU make being the interpreter that
   has to be built on the target before a p-f package can be built.)

If one wants to use something nicer than an unholy mixture of m4,
perl, and shell to implement a c/b/i language, strategies (2) and (3) 
are still available for making c/b/i programs directly executable
on target systems.

(2) is the more difficult, obviously, because the portable target
languages that are available are weak and problematic (sh and make).

One idea is to take a hybrid approach, a combination of the ideas of
(2) and (3):

Choose a clean, tiny language that is easy to implement portably.
Use this like imake -- something that is built, if not already
present, as the first step of a c/b/i invocation.   Call this the
"build-time language".

Use a larger, more complete language to implement the c/b/i language.
That is, compile the c/b/i programs not to sh+make but to the
build-time language.  Call this larger language in which the c/b/i
compiler is implemented the "development-time language".

(So, we have three languages here:


        ~ the c/b/i VHLL  (used to write c/b/i rules for a package)

        ~ which is implemented in the development-time language

        ~ and which is compiled to the build-time language
)


The hybrid approach may not be necessary.  If the build-time language
is sufficiently powerful, then no separate compilation phase is
needed.

But if compilation _is_ necessary, the nice thing about the hybrid
approach is that you can choose a build-time language that is easier
to target than sh+make.

Lua is pretty tiny.  You could, for example, bottle up lua so that it
could optionally be included in packages (like imake).  Design your
c/b/i language.  Then write a perl program that translates the c/b/i
language to lua.  (More realistically, you should choose a subset of
Scheme as your build-time language, full Scheme as the
development-time language, and implement the c/b/i language as a
collection of Scheme macros.  You get your compiler for free, that
way, and you get a free external syntax for all your data, and your
build-time and development-time language use exactly the same data
types so you don't have to do anything tricky in code generation.)


-t