Re: [jamboost] subvariants questions

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-27 17:29:26

----- Original Message -----
From: "Larry Evans" <jcampbell3_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Thursday, June 27, 2002 6:10 PM
Subject: Re: [jamboost] subvariants questions

> David Abrahams wrote:
>
> > From: "Larry Evans" <jcampbell3_at_[hidden]>
> >
> > > 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.
> >
> > There's really no need for that, since the bin/ directories are already
> > located in a place corresponding to that path.
>
> I was unclear. The v1 jam produces the bin directory in the same
directory
> where the Jamfile is located. For example, I've got a Jamfile in
> <top>/libs/smart_ptr/test/ and the bin directory is located the same
place.
>
> What I'm proposing is a location in:
>
> <top>/bin/<property_list>/<top_to_a_src_path>/a.obj
>
> with this scheme, everything below:
>
> <top>/bin/<property_list>
>
> would be compiled with the same properties; hence, the object files
> and library files can be linked together. As a side-effect, the code
> is reused. This is is contrast with having the a.obj file located in:
>
> <top>/libs/smart_ptr/test/ bin
>
> and:
>
> <top>/libs/cyclic_ptr/test/ bin
>
> and:
>
> whatever.
>
> Now the way jam works now

Keep in mind that we're discussing Boost.Build v2 here, not a modification
to the existing Boost.Build behavior. We have different plans for v2.

> is fine for libraries because they're put in
> a directory all their own and can be reused in a Jamfile like:
>
> unit-test main.exe
> : main.cpp
> ../../utility/src/obj_id.cpp
> <lib>../../cyclic_ptr/build/libboost_cyclic_ptr
>
> but the .o files, at least I don't think, can be similary reused. I'm
probably
> missing something.

I think you're missing something: free features don't go in subvariant
paths (because it would make them too long), and they may affect link
compatibility. For example, -DNDEBUG can change definitions, which results
in ODR violations if you link together files with different definitions of
the same type.

The current plan is to build everything from a (sub)project into a common
directory when the associated main targets have no free properties
specified differently from what's given in the (sub)project requirements.
That would prevent building any given .o twice for most cases of multiple
main targets in the same subproject.

> Maybe somehow you can specify a .o file as a main target
> and it's put in its own directory, like libboost_cyclic_ptr.a.

Yes, that's a possibility, but usually it shouldn't be neccessary.

-Dave