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
> > 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
> > 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
> targets alternatives. They all correspond to user-defined entities and
> 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
> > 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
> 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
> 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
> if new element should be added to subvariant identifier.
> I originally thought that you can do that in 'project-target.generate',
> this is not true, because main targets may be generated during generation
> 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
> 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.
> > 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!
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk