Re: [jamboost] Re: Spec draft

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-06-18 17:44:35

Vladimir Prus wrote:
> 
> Hmm... my idea what that FileSpec is not a target. It keeps the name of source 
> file, and just like MainTarget has 'generate' method --- which will create a 
> file target from the file name, and return it --- regardless of property-set 
> passed to 'generate'.

Why not just create the FileTarget then in the first place? If it is 
needed as a dependency, then it gets attached to the dependency graph 
(graph of Target), and if it is not needed, it remains unattached.

>>What we might really have here is
>>
>> Project (not a Target)
>> FileMetaTarget (cf. MainTarget) (not a Target)
> 
> 
> As I've said previously, the 'generate' method really makes sense for both 
> project and main target, so we need a common base for that.

As Dave pointed out, if it doesn't get used polymorphically, the base 
class is unnecessary.

> How does "AliasTarget" relate to the current "alias" rule? My understanding 
> that the "alias" rule should create an instance of MainTargetSpec which will 
> be generated as usual. I don't see the need for AliasTarget, as least for 
> now.

I just made it up to illustrate that there may be derived classes of 
Target other than FileTarget. We had talked earlier about a possible 
need for "GroupTargets" or "AliasTargets", so I just used that name...I 
don't know if it has a use yet.

>> o "project" and "project-target" a single class
> 
> 
> What's "project"? There's no such class for now. Or do you mean that function 
> of current "project.jam" file should be handled by the project-target class?

Yes. "project.jam" + "project-target.jam"

>> o "virtual-target" = "Target"
> 
> 
> OK. Only that it will be spelled "target" in code ;-)

I have no preference about the case.

>> o build an explicit graph of Target rather than pass around lists of
>>"virtual-target"
> 
> 
> I'm not sure what you mean. Could you clarify?

The current system doesn't generate an explicit dependency graph with 
all the "virtual-targets" acting literally as nodes. There is, of 
course, some equivalent representation of dependencies inside each 
"virtual-target" and its associated "action", but the graph is not made 
explicit and abstract in type so that one could, e.g., easily traverse 
the graph to compute the link-line library dependency order.

A motivation for the Target base class is for explicit representation of 
the dependency graph and abstract application of the "realize" function 
(which amounts to "actualize" now that we've determined that "generate" 
isn't really polymorphic among Project, MainTarget, and FileTarget).

--Ali