Re: [jamboost] Further development

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-08 05:50:46

From: "Vladimir Prus" <ghost_at_[hidden]>

> David Abrahams wrote:
>
> > I can only imagine that you mean something different by "Actual" as
used at
> > the beginning of the sentence, or that class "abstract-target" has no
> > correspondence to the category of "abstract" targets you're describing.
> > Either way, something needs to be clarified/renamed/reworded here. Are
you
> > sure you don't mean for the first kind of target to be called "main"?
>
> I don't think so. I see a similarity between projects, main targets and
main
> targets alternatives. They all correspond to user-defined entities and
all
> can be build, yielding a set of virtual targets.

I'll have to check out your reworded text to see if I understand this in
that context.

> > 2. What is the meaning of main-target.add-variant? Is this a different
> > meaning of "variant" than "debug/release"? Oh, I see that explained
> > somewhat in the comment at the beginning. I would prefer to pick a
> > different name; this overloaded meaning is confusing. I also don't
> > understand how these "other variants" will actually get created.
>
> The preliminary user docs I'm secretly writing use "alternative" to mean
the
> same. As for their creating: you can have
>
> exe a.exe : a.cpp : <toolset>gcc ;
> exe a.cpp : b.cpp ;
^^^^^
???

> Which would create two alternatives for main target 'a.exe'. The first
one
> will be used to the gcc toolset and the other for all other toolsets.

> > What does it mean for a project target to "cause the build" of a main
> > target?
> > I guess you mean what it does in its "main-target" method?
>
> Not exactly. I was thinking that main-target.generate computes a list of
> virtual targets for it. Then we need to compare free properties for each
> virtual target with free properties for the main target's project to
decide
> if new element should be added to subvariant identifier.
>
> I originally thought that you can do that in 'project-target.generate',
but.
> this is not true, because main targets may be generated during generation
of
> other main targets. For example:
>
> make a.exe : a.obj @/boost/c.obj : yfc-compile ;
>
> There, main target corresponding to c.obj will be found and its
'generate'
> rule will be called, but it will happen inside the 'generate' rule for
> 'a.exe'. It means that we should compare project's free properties with
> virtual-target's free properties inside 'main-target.generate'. Since
> 'main-target' keeps a reference to project it should be quite possible.

Once again, I'll have to look the file over again and see if I understand
this in the context of your new comments.

> Hint: to find all the properties with which a virtual target will be
> generated, you can first get the action for that target, and then call
> 'properties' rule for the action.

Thanks

> > helpful. Even redundancies like:
> >
> > # So, main targets
> > # keep a list of variants, which are instances of 'abstract-target'.
> > #
> > # Each variant is an instance of 'abstract-target'.
> >
> > tend to get in the way of comprehensibility.
>
> I'll make another pass through the docs. However, you probably know the
> problem that once any text is written and read several times by the
author, > bugs and poor wording tend to become familiar and hard to find
:-)

Yes. That's one reason it's important to try to be very explicit and
precise about what you mean the first time.

> > I still want to see an inheritance diagram.
>
> I'm preparing an UML diagam right now.

Great! Looking forward to it!

-Dave