Re: [jamboost] Re: Status of refactoring discussion

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-05-14 09:37:35

Vladimir Prus wrote:
> 
> > > Dave's idea to merge both hierarchies looked neat, but now I really
> > > don't think it's possible. Current virtual-target is needed *only*
> > > because Jam builtin targets are weak --- esentially there's the
> > > targets we are concerned about (and renaming virtual-target to
> > > target only stresses that).
> >
> > I agree with the second sentence but I don't see how it has any
> > relationship to the first sentence. If the merge is impossible, I
> > don't see why/how.
> 
> The first statement follows from the second and the following one...
> 
> > > Projects and main targets, OTOH, are just named entities which can
> > > be used to create different variants of ordinary targets.
> >
> > Not *just* named entities; there should also be a real Jam target
> > (and thus, a virtual target) associated with each of these things so
> > that its build can be requested.
> 
> No! What you say is contrary to what is now and what we've discussed
> previosly: if you request a build of specific main target, we don't create
> entire dependency graph and then only update part of it. We create only the
> dependency graph for this main target. Technically, we take a project-target,
> call it's 'generate' method and get all the virtual targets we need.
> 
> This pretty much work, so I don't buy your argument that real Jam target
> should be associated with projects and main targets. So, I think there's very
> little in common between the two kinds of target.
> 
> A littlbe bit more:
> - The 'generate' method from 'abstract-target' does not make any sense in
> 'virtual-target'. The latter corresponds to a file, built with specific
> properties. You can't ask a file to change its properties.
> - The 'actualize' method from 'virtual-target' makes little sense in
> 'abstract-target'. Yes, you can make it create and return jam target for the
> project. But it must depend on all variants of all targets in the project, to
> be usable. That means you must pass all requested properties to it.
> 
> IOW, to merge the hierarchies, you'll need base class with some polymoprhic
> methods. Can you give signatures of those methods?

[Moving my reply also onto the jamboost list]

...Volodya, the following was my query to you before reading the above
explanation of your objection...

Why not the following?

class target

class project : target
( contains main-targets, id, requirements, default-build )
( "actualized" as a NOTFILE Jam target )

class main-target : target
( contains configured-targets, id, default-build )
( "actualized" as a NOTFILE Jam target )

class configured-target
( contains sources, requirements, usage-requirements )
( "actualized" as a NOTFILE Jam target )

class generator # generates trees of new targets

class file-target : target 
( contains filename, type, action?, ... )
( "actualized" as regular Jam target )

class shared-lib-target : target
( ... )
( ... )

I think this may be a solution...we create the entire target dependency
graph, but note that we do not have to "actualize" the entire target
dependency graph! This is not any different than what is being done
now, EXCEPT that currently there is no "virtual-target" corresponding to
"project" and "main-target". True?

If indeed some "target" depends upon a "project", it would make perfect
sense for the project to have a NOTFILE Jam target associated with it. 
When the project is not involved in the build-request, no Jam target
gets created for it. Same for main-target, etc.

Then we have a single representation of targets that is consistent both
with the user's view of the world and the Jam view of the world. The
user usually directly specifies the top part of the graph (project,
main, configured targets), BoostBuild "generates" the rest of the graph,
and "actualizes" typically some lower portion of the graph which is what
Jam ultimately sees in its "actual" target graph.

Feedback?

--Ali