Re: [jamboost] (sub)project handling

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-12-03 07:56:30

David Abrahams wrote:

> > 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
>
> ;
No objections. Would be reasonable to have shortcut form -- i.e. to make the 
second argument optional, it which case value of the first argument is used.

> > 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.
The problems I see is that it:
1) Will defeat the aim of making Jamfiles declarative
2) Will cause building of extra targets when jam is invoked from subdir. This 
happens i some target is explicitly added to "any" dependencies.

> > 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"?
Yes, "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.

Actually, you suggest to hide Jam's primities (DEPENDS &c) altogether. In 
fact, this might be a good idea, as it's already impossible to work with jam 
without knowning something about Jambase, so plain primitives level is not 
usefull alone. Is making new declarative target primities what you'd really 
like?

> > 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) ;
> }
> }
Okay. For me it looks like the first thing to be written now... Just in case 
I'll have spare time, isn't this already implemented?

> > 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. 
Can it be imported to the global namespace?

> 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.
I'll mark it, thanks.

- Volodya