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

[Colin Walters]

I'd like to use this space to ask if there's been any progress made on
some of my merge requests?  You seem to have a lot of time to answer
email...

On Fri, 2004-04-09 at 13:34, Tom Lord wrote:

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

I agree.

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

For some definitions of "close" I guess :)  GNU make is way better than
POSIX make.  With the latest versions you even have $(eval).

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

You're forgetting about automake, but I understand your point.

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

I think the major problem you face here is that the language itself
can't use your c/b/i framework.

signature.asc
Description: This is a digitally signed message part