On Mon, Jan 17, 2011 at 6:31 PM, Paul Smith <[email protected]> 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 dependency. 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? oki, Steffen
