Re: [boost] jam build root

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-29 02:46:17

Larry Evans wrote:

> > Yes. Main target name appear in target path for a reason. Consider:
> >
> >         exe test_lje.exe : test_lje.cpp   ;
> >         exe test_lje_d.exe : test_lje.cpp : <define>DEBUG_EVERYTHING ;
> >
> > If main target name is not in target path, objects compiled with
> > different settings of DEBUG_EVERYTHING will be placed in the same
> > directory. BTW, this behavour will somewhat change in the new build
> > system, but still build system will take care of target path. Why would
> > you want to change the logic?
>
> I was hoping that test_lje_d.exe would go in:
>
>       bin/gcc/DEBUG_EVERYTHING/runtime-link-dynamic/
>
> or something similar.  In other words, everything that's compiled with the
> same options and compiler goes into a separate directory.  

The problem with putting free properties like <define> into target path is 
that it can easily make paths a way too long. 

> This allows
> writing test drivers such as:
>        lib/<my_lib>/tests/correctness/driver1/main.cpp
>        lib/<my_lib>/tests/correctness/driver2/main.cpp
>
> and then, if performance instead of correctness is to be evaluated:
>
>        lib/<my_lib>/tests/performance/driver1/main.cpp
>        lib/<my_lib>/tests/performance/driver2/main.cpp
>
> then maybe the jamfiles in correctness subdirectory would indicate the
> appropriate compiler options while those in performance would do likewise. 

It is intended that each project will be able to define "project 
requirements". This means that jamfile in correctness can require
<define>TEST_CORRECTNESS and the same applies to performance.

> Then, since the driver1 and driver2 jamfiles would probably include
> something from:
>        lib/<my_lib>/src
> the files from src would be compiled with either the correctness (i.e.
> debug options) and those from performance would be compiled with
> optimzation for speed.  In other words, they'd be put in either:
>
>       bin/gcc/correctness/runtime-link-dynamic/lib/src/class1.o
>       bin/gcc/correctness/runtime-link-dynamic/lib/src/class2.o
> or:
>       bin/gcc/performance/runtime-link-dynamic/lib/src/class1.o
>       bin/gcc/performance/runtime-link-dynamic/lib/src/class2.o
> This way, both correctness mains can share the correctness lib/src/*.o.
> and both performance mains can share the perofmance /lib/src/*.o.

Now I seem to understand what you mean. You refer to lib/src/class1.cpp in 
two main targets (lib/tests/correctness/driver{1,2}) and the file is compiled 
twice, right? Yes, such problem is present. In the new build system, it will 
be partially solved:

        exe main1 : main1.cpp lib.cpp ;
        exe main2 : main2.cpp lib.cpp ;

In this case, it is easy to note that neither main target has explicit 
requirements, and lib.cpp can be compiled only once. Your example can be 
handled like:

        # Jamfile in lib/tests/correctness
        exe driver1 : driver1/main.cpp lib/src/class1.cpp ;
        exe driver2 : driver2/main.cpp lib/src/class1.cpp ;

Is this solution ok? Another approach would be to define new feature, say 
"testing-type", with values "correctness" and "performance", then to make a 
library of lib/src/*.cpp and use it for test drivers. This approach might 
even work in the current system (sorry, have not tried yet, so may be wrong)

> Of course, maybe I'm missing something.  If so, please help me find it :).

Or maybe it's me who's missing something, and knoweledge of what you'd like 
from the build system is very important.

- Volodya