From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-15 04:52:49
David Abrahams wrote:
> > I'm in opposition again :-) Please see the parallel post, where I
> > talk about subvariants and relevant properties.
> What is your concern about property relevance? The only thing it gets
> used for is determining target location.
Because it also determinies the exact set of targets that are build and I
think it's important that boost system don't do any unnecessary actions.
> > Are you sure this is good enough criteria? There's only one example
> > of using optional properties in your email, and I'm not unsure about
> > it.
> What do you mean by "I'm not unsure about it?"
Either "not" or "un" should not have been left.
> These criteria handles things like target-type specificity. Properties
> in an inheritance/refinement hierarchy can be composite properties
> which expand to add properties for all of their bases. So for example,
> might expand to
> <target-type>PYD <target-type-base>PYD
> <target-type-base>DLL <target-type-base>executable
> (see http://groups.yahoo.com/group/jamboost/message/88 if you need to
> refer to the target-type refinement hierarchy). A generator which
> wanted to match all executables might specify
Say there another generator, with
Clearly, if you want to build PYD and no specific generator specific to PYD
is present, generator for DLL should be selected. How will it be given
precedence over <target-type-base>executable. Or do you plan to always have
default generator for each type, which generator will simply change target
type to that of parent and invoke the matching process once again?
> > I don't fully understand. Do you mean <source-type> is needed to
> > match the last transformation?
> Actually, no. I realize I didn't explain this fully. <source-type> is
> there as an optimization for the case CPP->OBJ. Any time you can cause
> a more-specific generator match you can avoid potentially-expensive
> search through other generators (e.g. a PASCAL->OBJ generator).
I see. And we can work without <source-type>, by means of selecting the
generator with the less nonzero number of targets, right?
> This requires a small modification to the procedure I outlined
> earlier. I thought we might need this anyway: after generating
> these "targets" (just objects so far, not targets in the core Jam
> sense), we recurse through the dependency graph and generate the
> real targets and build actions.
Yes, this is needed, I think.
> I wonder if this handles things like STLPort. Hmm, let's see: we want
> the STLPort executable generator to be invoked preferentially to any
> one toolset's generator. This generator will add <sysinclude> paths,
> etc., to the build request, then re-invoke the process to generate the
> We can add
> <toolset> <target-type>EXE <target-type>DLL <target-type>IMPLIB
> to its optional properties, and <target-type-base>executable to its
> required properties. That should suffice.
This is kind of magic to me :-) If you'll have another generator with
required properties <toolset>gcc <target-type-base>executable, then will
STLPort generator be selected becuse of extra <target-type> match?
> How does that sound?
This starts to sound more attractive than before.
Let me try some use cases.
Suppose we want <stdlib> property. Will STLport executable generator have to
consult the value of this property? If there's another standard library
STLnonport, will generator for it have to consult the property as well. If
there two generators (from STLport and STLnonport), which one will be
selected? I presume we can't run both?
2. Consider my favourite transformation sequence:
asm.wd -> asm_parser.whl, asm_parser.dlp
asm_parser.whl -> asm_parser.cpp
asm_parser.dlp -> asm_parser.cpp
Both cpp a then compiled and linked.
exe foo : asm.wd ;
When searching for transformations, the will be two pathes leading to asm.wd.
We'd need, during second pass (which computes targets &c), to make sure
transformation from wd to whl and dlp won't be run two times.
3. What would you say about the idea of having special executable kind called
'unit-test-EXE', which will do almost the same as 'EXE' but will run the
executable. Looks like all that is needed to the define transformation with
So far I don't see any problem. I'm still unsure about the matching
algorithm. Can we insure that any particular transformation will be run
first? Can poorly written transformation take precedence just because it has
a long set of optinal properties. Won't it be easy to create such a incorrect
transformation by mistake? I don't have any examples, but it scares me a
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