Re: [jamboost] Development plan

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-09 19:24:29

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Tuesday, April 09, 2002 1:54 AM
Subject: Re: [jamboost] Development plan

> David Abrahams wrote:
> > ----- Original Message -----
> > From: "Rene Rivera" <grafik666_at_[hidden]>
> >
> > > Maybe getting "exe" working with "gcc" is simple enough? Don't
know
> >
> > what you
> >
> > > guys usualy use for a compiler though.
> >
> > That sounds good to me. I have gcc on both my windows and linux
system.
> > Let's go for 2 different versions, though, as proof-of-concept: How
> > about 2.95.2 and at least one 3.x.x version?
>
> Sure, gcc is ok for me too. I only think that this is quite distance
goal. I
> can suggest something in between.

Hey, the smaller the first goal, the better!

> 1. First, we write a single rule called "make" or "generate"
>
> rule make ( targets + : sources * : command-to-run )
>
> This rule would just construct dependency graph (of "virtual
targets"), then
> convert it into actual target and build it. This way we'll
> - have something working -- it's just nice to have
> - have chance to play with virtual targets and finilize its design
> - such rule is usefull anyway

Not sure I understand this suggestion. What is "command-to-run"?
Is this just a rule which constructs a simple dependency graph of depth
2?

> 2. Second, we make the link between projects/abstract targets and
virtual
> targets. Abstract targets corresponding to project will have
'generate'
> method, that should return virtual dependency graph. Ultimately, it
should
> use generators to find that graph. At this stage we'll just have a
stub rule
> that, instread of running the right algorithm, will either contain
hardcoded
> logic, or consult some decision cache.

Please elaborate. I get a vague sense of what you're suggesting, but
it's not solid for me yet.

> At this stage we can support
> 1. Two toolsets (gcc 2.95 / gcc 3.0)
> 2. Two build variants
> 3. Two simple features (inlining and threading, for example)
> 4. One fancy feature ( stlport/stdlib )
>
> 3. Everything, including proper dependency graph construction for the
two
> selected toolsets. Some more features.
>
> How does that sound?

I like it in principle. Needs a little flesh on the bones.

Best,
Dave