Re: [jamboost] Development plan

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-04-11 09:46:18

David Abrahams wrote:
> ----- Original Message -----
> From: "Vladimir Prus" <ghost_at_[hidden]>
>
> > I imagine two possible alternatives.
> > 1. It is literal string ....
> > 2. It is name of a rule ....
> I guess I would opt for 2. in this case because it's less limiting.

Agreed. 

> > * Supported functionality. *
> >
> > ***
> > First is the 'make' rule I was talking about. Let's extend it a bit,
>
> and
>
> > allow this usage:
> >
> > project test
> >
> > : requirements <inlining>full
> >
> > ;
> >
> > make foo.obj : foo.cpp : gcc-compile ;
> > make foo.obj : foo.cpp : gcc-compile : <optimization>full ;
> >
> >
> > This will create two targets, with different properties (and different
> > locations, accordingly to project-specific properties, explicit
>
> properties,
>
> > and ALL_LOCATE_TARGET (which will be renamed, of course) ).
> >
> > The name of target targets , sources targets and property list will be
>
> passed
>
> > to the gcc-compile rule, to to whatever it like. At this stage,
>
> conversion
>
> > from property list to compiler options will be hardcoded.
> >
> > Probably, we can just ignore build request for now.
>
> 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. 

> > What problems are there? First, we need a mechnism to select obj of
> > all the subvariants that are available in subdir -- i.e. a way of telling
> > which properties are compatible and which are not -- I don't think we have
> > it ready.
>
> 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 and if subproject requrement, when combined with inherited ones, 
leave any change of building.

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

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

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.

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

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

- Volodya