Re: [jamboost] Re: [V2] Problems with stage rule

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-14 03:01:29

Kirill Lapshin wrote:

> Please find attached the test case. I changed your
> test case a little, added toplevel jamfile which has
> 'build-project d ;' statement. Now if you do 'bjam'
> from subfolder d it will create dist in root folder as
> expected, however if you do 'bjam' from top folder it
> will place dist under d.

Thanks, I now see the problem. It's simple: path-constants
are relative to invocation directory. The 'make' example
I've given to you some time ago makes uses of it. But 
the value of <location> is considered relative to Jamfile's directory.

The only solution I could imagine is to convert values of all path constants
to absolute paths. The absolute paths are ugly, but this works, although a
nicer solution is welcome. The fix and tests are in CVS now. 

>
> I have one more question, completely unrelated to
> current problem. Suppose I have a project consisting
> of a few dlls, some of them linked directly or
> indirectly with executable, while others loaded
> dynamically. For those which loaded dynamically I want
> to introduce dependency without actually linking them
> with exe. So that every time I build executable all
> the dlls it depends on got updated as well. Also if
> this executable is a test then it is important to
> update dlls before executing the test. How can I
> express this in jam?

Until recently, you could have used:

lib plugin1 : plugin1.cpp ;
exe host : host.cpp : <dependency>plugin1 ;

This causes building of "plugin1" whenever "host" is built. Futher, "host" 
will depend on "plugin1" and will be updated is that has changed. Is that 
what you're after?

There's only one problem: now <dependency> does not add dependency :-)
The reason is that primary use case for it was getting usage-requirements, e.g

exe main : main.cpp : <dependency>@/boost ;

to get proper includes for Boost. Building the entire Boost is not desirable 
here. I think the right ultimate solution is to have two properties

<uses> --- "weak" dependency, only grabs usage requirements
<dependency> -- "strong" dependency, as it was before.

Is this look sensible? In either case, this can't be implemented instantly, 
unless you want to help with it ;-)

- Volodya