Re: Request for comments: CONS specification

[Pierre THIERRY]

> Developing a new extensible version of cons is a good idea.

I agree. ;-)

> it makes sense to think of the new CONS as at least two layers: A
> [simple and optimized] core build engine [...] and modules on top of
> the build engine which contains the 'expert' systems

Yes. It's exactly what I was writing in another mail... It is exactly
the Modularity design goal.

> What I'm proposing is to migrate qs into the new cons as the core
> build engine.

I'm not sure if qs should be the core of the new Cons. I want to design
entirely from scratch a new Cons, and then build the code in respect to
the specification. The latter will include a documented API to link an
interface to the core system. If Qs could be modified to expose this
API, or if a Cons-API front-end could be written for Qs, it could at
least be an alternate core.

If Qs meets the specifications of the internals of the Cons core, we can
try to use it as the main core.

But all authors must agree to licence their code in a GPL-compatible
manner, if not in GPL.

> This architectural division will also ensure that users will always be
> able to bypass the upper layer to do whatever they want.

With or without layers (but I don't think coding Cons properly could be
achieved without layers), being able to call Cons without the Articifial
Intelligence we will get on top of it is mandatory. TIMTOWTDI.

> It might be interesting to complete this so that the new cons is
> actually contains an export builder which gives back wards
> compatibility with old project. This could ease the transition from
> old cons to new cons.

I see this as a must-have, except for some very complicated Construct,
that are more a specific software built on top of Cons...

> Another area I would like to improve is the debugging of the
> dependency graph.

Yes. I add a design goal: Verbosity. A major type of Cons user is a
developper, and when something goes wrong, Cons should be able to give
him accurate information about the problem.

> It was also suggested earlier to add native support for build
> clustering.  That would be a very cool feature.

I will not develop a Cons that is not clustering enabled... If Cons is
modular, it's nearly straightforward to add this ability, so it would be
a nonsense if we don't. In addition, not everyone has a computer where
parallelization will be much faster (if one of you has informations
about the exact efficiency of building in parallel, it would be great,
as it would be needed to set the default settings of parallel building
in Cons), but it's not unlikely to have one or two other systems where a
remote shell is available.

Regards,
le Moine Fou
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature