[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Colin Walters
Subject: Re: [Gnu-arch-users] Managing changes to projects that use autoconf/automake with tla
Date: Fri, 09 Apr 2004 16:08:23 -0400

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

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]