Re: [jamboost] (sub)project handling

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-28 10:16:32

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

>
> Here are questions that I find important:
>
> 1. What will be the syntax for indentifying projects
> project foo ;
> and then
> subproject foo/src ; or
> subproejct src ; or
> project foo/src ;

I have been thinking about this a bit. Should it be possible to identify a
subproject according to something other than (strictly) the path from the
root to the Jamfile? For example, the boost.python jamfile is in
boost-root/libs/python/build

Shouldn't it be possible to identify that subproject as simply boost/python,
so that from the top of boost you can do:

jam python
or
jam boost/python

So, what about this?

project boost/python # (sub)project target id
: libs/python/build # optional path from project root
;

> 2. David has proposed that Jamfiles should be declarative: first some data
is
> gathered and only then build instructions are generated. Is this
sufficient
> for all uses? What if somebody wants simply to define some targets?

I don't understand the problem.

> Related problems is inclusion of top-level Jamfile. I've tried that to
insure
> complete build from and subdir (which was not good idea), but if we have
^^^ "any"?
> subproject requirements, we'd need some way to included Jamfiles on that
path
> from top to current dir, without any side effects.

Well, with no side effects other than the obvious recording of declarative
info.

> Explicit target creation won't work with it, will it?

I'm still not sure I see the problem.

1. Explicitly created targets will end up in the dependency graph, but so
what?

2. If we provide new declarative target primitives, users can "explicitly
create" a target declaratively, so that it interoperates with the rest of
the system.

> 3. If declarative semantics is agreed upon, what data structures will we
use.

Lists of strings ;-)
Seriously, though: let's look at what we need.

Each Jamfile will be loaded as a distinct module. Target declarations can be
stored in module local variables. We'll need:

1. A list of the target names declared in the Jamfile. That's easy; we can
store that in a list of strings.

2. For each target, its sources, dependencies, requirements, and default
build. Also relatively easy: we can store each one in a variable whose name
is based on the target name. For example:

rule declare-target ( name type levels ? : sources * : dependencies * :
requirements * : default-build * )
{
levels ?= 2 ;
local jamfile = [ CALLER_MODULE $(levels) ] ;
module $(jamfile)
{
module local __targets__ ;
# need an error check here
__targets__ += $(name) ;
$(name).__sources__ = $(sources) ;
$(name).__dependencies__ = $(dependencies) ;
$(name).__requirements__ = $(requirements) ;
$(name).__default-build__ = $(default-build) ;
}
}

> 4. (completely unrelated to the subject)
> Is there a way for a module to define rules at global scope? To declare
rule
> using dynamically computed name? I was thinking about a rule like
> "declare-main-type". E.g.
> declare-main-type exe ......
> could create global rule called exe.

Not exactly, but you can declare a rule and import it into any module using
a dynamically computed name. I think I see what you're trying to do, but I
doubt it would work. The problem is that no part of the rule you're defining
is evaluated until the rule is executed.

However, if the rule's implementation calls another rule, you could use
BACKTRACE to find out the name of the calling rule, and use it to generate a
target type.

I discovered a few days ago that you can invoke Jam with -f-, which reads
from standard input. In fact, you can use -f<some file> -f-, which reads
from <some file> first, then reads from standard input. When you hit EOF, it
wille evaluate what you type. That can be useful for experimentation.

-Dave