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
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
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
> >> o build an explicit graph of Target rather than pass around lists of
> > 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.
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
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.
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