Boost logo

Boost-Build :

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2002-06-27 13:04:15


Vladimir Prus wrote:

> David Abrahams wrote:
> > From: "Vladimir Prus" <ghost_at_[hidden]>

[snip]

>
> Anyway, let' return to the ordinary scheme. In v1 target paths for main
> targets have the form:
>
> main-target-name/<property-list>/main-target
>
> for example
>
> a.exe/release/runtime-link-dynamic/a.exe
>
> I like this naming. But when thinking about intermediate targets, I got the
> idea that nothing requires us to store objects used by main targets together
> with them -- after all, we don't expect anybody to link binaries by hand?
> I therefore propose to make paths for main an intermediate target almost
> uniform. I.e. an object file used by a.exe would be stored in
>
> a.obj/release/runtime-link-dynamic/a.obj
>
> if its free properties are the same as for its problems. If the same file is
> used by b.exe which explicit requirement include free properties, the path
> would be
>
> a.obj/release/runtime-link-dynamic/main-target-a.exe/a.obj
>
> Opinions?
>

What about:

<property_list>/<top_to_a_src_path>/a.obj
<property_list>/<top_to_a_target_path>/a.exe

? In the above, the <top_to*> symbols are essentially the
subinclude paths in the Jamfiles, i.e. the path from the "top" directory to
the source file directory or main target directory.

The Jamfile for <property_list>/<top_to_a_target_path>/a.exe
would specify just <top_to_a_src_path>/a.obj and bjam would
preprend the <property_list> to get the target directory for the a.obj file.
Any other Jamfile using the same <top_to_a_src_path>/a.obj and same
<property_list> would reuse the <property_list>/<top_to_a_src_path>/a.obj
and save the time and space of recompiling the a.obj file. In essense, it just leaves
off the a.obj prefix from the above proposal for the a.obj directory.
I guess your main-target-a.exe above corresponds to my <top_to_a_target>.

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk