27 Oct 2004 03:05
Re: CONS specs update?
Pierre THIERRY <nowhere.man <at> levallois.eu.org>
2004-10-27 01:05:00 GMT
2004-10-27 01:05:00 GMT
> I'd hate to see yet another effort to revive Cons drop flat. So do I. Sorry for the very long silence, I didn't find time to sit on a table with a notepad, and think about how everything the discussed about could fit together. I think I was lacking inspiration to do the synthesis of that... But the inspiration came, at last, thanks to my readings about semantic web, and RDF. I think that there is a very simple way to achieve the nearly-AI and moudlar CONS we talked about. Here is how I sum up the thread. CONS, to build something, needs: - a dependency graph, describing what the parents of each file or group of files are, and the steps (processes) needed to build the file(s) with their parents, - the build steps can (should) be separated from this dependency graph, and consist of a (big) set of very small graphs, - all the source files that are needed to build a complete graph pointing to the wanted resulting file(s), - all the build tools needed in the various build steps. So, in fact, and that was what was blocking me, the various CONS modules just need to be able to communicate graphs and trigger commands. Trivial, isn't it? And for what I know, RDF is just the most complete and practical (and widespread...) way we have today to represent relations between objects. So here are the core modules of CONS: - Builder: given fully-constructed dependency and steps graphs, it triggers the modules that can handle the steps of the dependency graph, - Local-Command: given a fully-constructed step graph involving only commands locally present on the computer and the source files, it triggers the commands, - Remote-Command: given a fully-constructed step graph involving only commands remotely present on a computer and the source files, it triggers the commands. We need at least the following optional modules: - Construct: it provides a Perl API to construct a dependency or step graph. Then, we would be free to implement whatever existing or desirable module the way we want, and in the programming language we prefer, because we have an independant communication protocol. This could include the guessing system, and improving the builder. I see two major possibilies: if the standard one does not build in parallel (it would be a shame if it doesn't, but it could be easier to implement a very trivial one at first), a Parallel-Builder module could replace it, and we could imagine a Fast-Parallel-Builder module, that would be able, for example, to estimate the time needed for some steps, and would execute the steps in such an order that the builds is performed faster... Everything is possible. Does someone has objectons about the use of RDF for dealing with graphs communication, and the modular design I describe here? Nowhere man (aka le Moine Fou, having changed nick and email inbetween) -- -- nowhere.man <at> levallois.eu.org OpenPGP 0xD9D50D8A
_______________________________________________ Cons-discuss <at> gnu.org http://lists.gnu.org/mailman/listinfo/cons-discuss Cons URL: http://www.dsmit.com/cons/