Re: [jamboost] Development plan

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-04-12 08:45:11

David Abrahams wrote:

> > Good question. As soon as I started replying it, I've realized that
>
> make
>
> > semantics I've given above is not right/needed. Instead
> >
> > make targets : sources : rule : requirements ;
> >
> > should mean almost the same as usual rules:
> >
> > subvariants of 'targets' can that satisfy requirements can be build
>
> from
>
> > 'sources' by invoking the specified rule (and passing it targets,
>
> sources and
>
> > full property set). So the difference from usual rules is that build
>
> actions
>
> > are not generated by explicitly given.
>
> So this appears to be the equivalent of the current
> "declare-local-target" rule. Correct?

Roughly so, except that declare-local-target is much more sophisticated and 
that "make" rule can be invoked several times for the same target.

> > and if subproject requrement, when combined with inherited ones,
> > leave any change of building.
>
> Do you mean "change" or "chance"?

"chance"

> > BTW, can you clarify the difference between
> > "optional" and "symmentic" features? I can't understand it from docs.
>
> In the current system, <runtime-link> is a symmetric feature. A value is
> always chosen for every build, but its default value (dynamic) is not
> automatically incorporated into build variants. The result is that the
> corresponding subvariant directory always shows up in the subvariant
> path, so that subvariant paths always include runtime-link-dynamic or
> runtime-link-static. Compare this with, say, <optimization>, which gets
> a value in each build variant. In a normal debug build, you don't see
> .../optimization-off/... in the subvariant path.

Understood. It was the phrase "not automatically included in all variants" 
which has confused me. Maybe the comment should be clarified.

> An optional feature need not have a value ....

Understood.

> > Let's go back to what I wanted. I'd like an ability to link together
> > targets which are not, strictly speaking, compatible, for example to use 
> >some library with space optimization even in release builds, which 
> > optimize for speed.
>
> Ah. There are two levels of compatibility. The first level is
> link-compatibility. On all toolsets I know of, all <optimization>
> settings are link-compatible with one-another, and there should be a way
> to link them together. In fact, if we take Ullrich Koethe's suggestions
> from
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Configura
> tion_And_Installation it will be important to be able to do so,
> especially when the resources (e.g. source files) for constructing other
> build variants are not available. 

Okay.

> However, I see no need to override
> true link-compatibility restrictions. In other words, you shouldn't be
> able to link together object files generated with a different alignment
> requirements, EH model, etc... 

Agree.

> The second level is something much vaguer: "request compatibility" or
> something. Normally, if I'm making a debug build of my application with
> optimization on I want the build properties to propagate to all the
> libraries I can build which are linked into my app. However, that's not
> always true, and the requested properties may only propagate to a subset
> of my app's dependencies. The question is, if we allow it to be
> customized, where will this "request propagation" be specified? Shall we
> allow the user to put it in the build request somehow, for maximum
> flexibility, or would it be better to just have a way to write it in the
> Jamfile? My sense is that it's just too complicated an idea for the
> command-line, and it should go in the Jamfile.

I agree. Saying something like: "grab space-optimized version of library foo 
when linking app bar" is too complex to say in command line.

> > The syntax
> >
> > exe main : main.cpp *lib/lib1/<optimization>space ;
> >
> > therefore should mean something like: when deciding which variant to
> > link in, pretend that build request contains <optimization>space, no 
> > matter what is in the build requrest for the "main" target.
>
> Okay, I like that. Now you need to specify what happens if
> <optimization>speed happens to be in the requirements for lib/lib1. My
> feeling is that, since <optimization> settings are link-compatible, it
> should link with <optimization>speed and issue a suitable warning
> depending on the verbosity setting. If <optimziation> were not in fact
> link-compatible, should there be a hard failure or should it build
> anyway?

I'm in favour of hard failure.

>
> BTW, why are you not using '@' to denote targets? Shouldn't that be
> @lib/lib1/<optimization>space?

Yes, it should. Thinko on my part.

> > Is it syntactical or semantical distinction? I mean that "make" rule
> > return dependency graph, but while future "exe, lib, &c" rule would 
> > construct it,
> > "make" can create it from it's arguments very simply. Under refined
> > semantics, it will have to do something: filter build request with
> > requirements, for example. Only the graph with have depth 2 and this
> > is the simplification I like.
>
> I think your idea is growing on me. I'm not sure what it means to
> "return a dependency graph", though. Are you suggesting that it returns
> a list of virtual target names? Actual target names? Something else?

A list of virtual target names.

> > > in other words, I'm not sure
> > > just which problems "make" is supposed to solve.

> > First purpose is temporary -- to serve as a test tool.
> > Second is been unsure that our generators algorithm with cover 100% of
> > cases.
> > I hope I wil cope with 99%, but "make" is a tool to explicitly specify
> > dependecy graph for the remaining 1%.
>
> OK, I like your plan.

Great. I indend to think about details a little bit more over weekend and 
write some tests for "make". I hope it will make the set of tasks more 
definite.

- Volodya