Re: [jamboost] Re: Spec draft

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-19 09:01:44

Ali Azarbayejani wrote:
> 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.

I had explained that already, I think. Did you seen the email with the 
following code:

for s in sources:
source_targets = []
TargetSpec t = targets.find(p.value())
source_targets += t.generate(build_properties)

? The FileSpec class would be very usefull generalization. Also, take a look 
at current 'targets.find' rule and it's use in 'generate-from-referene'. 
(line 595 in the current targets.jam). The 'find' rule returns either 
instance of abstract target or instance of virtual target and the caller 
users rtti do decide what to do. That creams for a FileTarget class, and in 
fact the ugly code is there because I hoped that a new design where 'find' 
will return some base class will soon appear.

>
> >>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.

I think I was saying that already. They *are* used polymorphically! User can 
write:

bjam /boost/filesystem foobar

and build system will locate two abstract targets : one for *project* 
/boost/filesystem and another for *main target* foobar. It will can 
'generate' method, not really caring what the real type is. Moreover, I 
imagine user can write

stage all : /boost/filesystem foobar file.cpp ;

It's reasonable to implement this by constructing instance of 
'abstract-target' for each source (or TargetSpec), and call 'generate' method 
on all of them. Again, the code in main target does not care for real type of 
source --- it can convert them all to a list of virtual targets, and that's 
enough.

> >> 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.

Do you have a specific algorithm for computing library order using dependency 
graph. Also, do you think that if library "a" should come before "b" in link 
line, there should be *dependency* from "b"'s targets to "a"'s target. I 
believe the last statement is not true. 

Imagine
exe main : main.cpp a b ;
lib a : a.cpp ;
lib b : b.cpp : <uses-symbols-from>a;

Now, "a" should come before "b" in link line, if you're linking "main". But, 
there should be no dependency from "b" to "a". IOW, if I run

bjam b 

then "a" should not be compiled -- it's really not needed for anything.

> 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).

Did we? IMO, it's is polymorphic among Project and MainTarget. And with my 
scheme for FileTargetSpec, it polymorphic for it, as well.

- Volodya