Re: [jamboost] Development plan

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-11 11:05:54

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> > Well, build request expansion is already implemented. See
> > build-request.jam.
>
>
> I know that. I suggested to ignore build request for another reason --
I'm
> not sure what semantics it will have since make rule essentially
specifies
> properties for the targets built, not filters build request. But see
below,
> where I change my mind.
>
> > It's not clear to me where you envision this 'make' rule being used,
> > though. Can you tell me what it's place in
> > www.boost.org/tools/build/architecture.html is?
>
> 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?

> > I'm not sure. Certainly build-request.jam is using some notion of
> > compatibility... oh, it's a different notion than what we need for
> > dependency target requests. What we need is something like what we
do
> > with gLINK_COMPATIBLE in v1.
>
> And besides, we'd need to an ability to check if build request satisfy
target
> requirements

Yes.

> and if subproject requrement, when combined with inherited ones,
> leave any change of building.

Do you mean "change" or "chance"?

> > There is also a need to deal with "propagated" features (see
> > features.jam).
>
> A, yes. I've forgot about them. 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.

An optional feature need not have a value. A typical optional feature
might be the version of a toolset to use. So, you might request a gcc
build, or you might request a gcc-3.0.3 build. The former would have no
<toolset-version> feature, whereas the latter would have
<toolset-version>3.0.3. In the former case, it presumably would be built
with whatever GCC toolset you get by invoking "gcc" without "-Vnn".

> > > Second, I believe we need a mechanism to bypass that selection and
to
> >
> > say:
> > > "give me target with such and such properties".
> >
> > Hmm, I think you might be misunderstanding something here. You first
> > said: "we need a mechnism to select obj of all the subvariants that
are
> > available in subdir". But the subproject doesn't make specific
> > subvariants available, really. What actually happens is that the
> > requirements on a target specification *rule out* some subvariants.
So
> > you can always ask "give me a target compatible with such-and-such
> > properties" but the system may say, "sorry, I can't because the
> > following target requirements conflict with your request".
>
> 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. 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... (OK, maybe as a feature, much later, for
hackers, we need something like this)

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.

> We should have either a way to specify that in the target which uses
the lib,
> or in the lib target itself.
>
> 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?

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

> > > I propose that make rule would just create a special abstract
> > > instance. Instread of calling generators, it would return a
dependency
> > > graph directly.
> >
> > I think "dependency graph" might be conferring more legitimacy upon
> > what's built at this stage than appropriate. It seems like you are
> > really just saying that make creates a record of its arguments.
>
> 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?

> > > Here's a problem
> > >
> > > make a b c : d : some-action ;
> > >
> > > Will three abstract-targets be created? Or just one? In the latter
> >
> > case, with
> >
> > > what name? Or will we ultimately decide not to give the user such
a
> >
> > low-level
> >
> > > rule as 'make'. I have a feeling that would be a mistake.
> >
> > We don't need to expose anything we're not comfortable with to
users.
> > I'm not really sure whether make should take multiple elements in
its
> > first arg, since I don't know what you're aiming at with it. I'm
sure
> > you have something in mind, but the way you're writing this it
sounds
> > like a solution in search of a problem... 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.