[Top][All Lists]

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

Re: [CRAZY PROPOSAL] Automake should support only GNU make

From: Steffen Dettmer
Subject: Re: [CRAZY PROPOSAL] Automake should support only GNU make
Date: Mon, 17 Jan 2011 20:10:32 +0100

On Mon, Jan 17, 2011 at 6:31 PM, Paul Smith <address@hidden> wrote:
> On Mon, 2011-01-17 at 17:28 +0100, Steffen Dettmer wrote:
>> When having a source three constructed of several (sub-)
>> packages, how does a Beta-Build system looks like? Could there be
>> tupfiles including sub-tup-files?
>> What influence has the choice of a Beta-Build to the
>> maintainability of such a sub package? Can they still be
>> orthogonal to each other?
> I don't offhand see any reason why a Beta build system couldn't
> use the same makefile syntax as make, even GNU make.  It seems
> plausible that the parser which creates the DAG, etc. could be
> kept basically as-is.  However, I think the "walk the DAG",
> build decision parts of make would have to be tossed and
> completely re-done.

I was just wondering what happens in a parallized build, let's
say when component B uses several headers from component A which
are automatically generated, but component B should not need to
know anything about component A's "internals". With make, someone
could have some a/build.mak and b/build.mak and have the Makefile
include both (would this be the correct approach?).
Would be a problem if component B would need to tell (to know)
that component A's header depends on some project configuration
option or so.

If I understood correctly, there were attempts to make make a
"beta-builder" by adding such functionality, this probabaly used
the same Makefiles which would be a nice advantage, because it
could make "betagmake" a drop-in replacement. I leaves open how
suited Makefile syntax is for a Beta-Builder.

I think a good Beta-Builder would not need to get any
dependencies hand-written in some Betamakefile, but could derive
all this automatically. In first runs this might require to
rebuild targets (in the case an input was found changed: the
dependency could be added automatically and the target could be
rebuilt to fix this build error automatically). The Betabuild
would learn all dependencies by watching what the subprocesses
(triggered by the building: like compiler, linker, source code
generators etc) open as input (read). If "gcc main.c" opens
"parser.h", it would know that main.c depends on parser.h - no
need for any makedepend anymore; deps would fully support all
conditionals, source code generation and no one could forget a

Is this correct or is this impossible to archive?

>> How portable can a Beta-Build system be? Isn't it requiring
>> specific extentions to watch the file system by some event bus or
>> such?
> That would be one way, and is certainly the most efficient.  Another
> would be to simply stat all the files up-front; that could be done on
> any system.  Obviously this is much more time-consuming.  On the other
> hand you can avoid a lot of rule matching/searching/etc.

I didn't understand what "stat all file up-front" means or how to
archive it. Do you mean stat'ing all files?
When instead of watching calling stat() on each file to find out
whether it was changed, wouldn't this be O(N) and thus an Alphabuilder?



reply via email to

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