Re: [boost] jam build root

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-02-05 03:43:30

Larry Evans wrote:

> > 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
>
> Almost, but not quite.  I would like to avoid mixing code in the same
> directory which doesn't pertain to each other.  For example,
> driver1/main.cpp has nothing to do with driver2/main.cpp.

Actually, neither cpp nor obj files will be mixed in this case. Obj will live 
in bin/driver{1,2}..... . The only problem is that Jamfile refers to two 
unrelated targets. This is need becaue it's not planned to handle multiple 
compilation of source files in different directories. I.e. it is agreed that 
in the above example class1.cpp can be made to compile only once. Maybe, it's 
possible to compile it only once when rules for driver1 and driver2 are split 
across two Jamfiles, but this needs for thought.

> This is what I'd like:
>
> Currently I'm using gnu make and provide it with
> two macro arguments, TARGET and BUILD as well as a target, e.g. link.
> TARGET and BUILD are directories containing target.imk and build.imk
> files, respectively.  The target.imk specifies what program to build and
> the build.imk specifies what compiler and options to use.
>
> It may help to view the directory heirarchy.  Here it is:
> <---------- directory heirarchy---------------
> boost/dev/Makefile
> boost/dev/build_variants/gcc/compiler.imk
> boost/dev/build_variants/gcc/debug/build.imk
> boost/dev/lib/col_io/tests/common.imk
> boost/dev/lib/col_io/tests/marg_buffer_put/main.cpp
> boost/dev/lib/col_io/tests/marg_buffer_put/target.imk
> boost/dev/lib/col_io/tests/marg_ostream/main_cout.cpp
> boost/dev/lib/col_io/tests/marg_ostream/target.imk

> So, to build:
>    boost/dev/build/gcc/debug/lib/col_io/tests/marg_ostream/main_cout.exe
> I invoke make as follows:
>    make TARGET=lib/col_io/tests/marg_ostream BUILD=gcc/debug link
> This produces, as needed, the  *.o *.o.dep and *.exe files in
>     boost/dev/build/gcc/debug/lib/col_io/src/
>     boost/dev/build/gcc/debug/lib/col_io/tests/marg_ostream/

Oh, so this is how build variants are handled with make!

> The *release.log files simply record which version of the files are used to
> create the .exe file.  They are produced with the release target instead of
>  the link target in the make command.  

And then you are able to say which files versions make an executable? Hmm.... 
this might be good with version systems that don't have global revision (like 
CVS, that I mostly use). I'd need to think how we can optionally add such a 
behaviour.

> This also vc's any file that doesn't have the used file stored in RCS.  

I would not like any automatical adding myself, but again, such possibility 
should be considered -- I think it can be done but not sure about details.

> The content of the marg_ostream/target.imk file is:
> <---------------- marg_ostream/target.imk --------------
> IMK.pops:=$(shell perl -e 'print $(IMK.pops) + 1')
> include $(shell echo $(IMK.path)/common.imk|tee -a Makefile.d)
> IMK.pops:=$(shell perl -e 'print $(IMK.pops) - 1')

Uph... I really can't grasp what's going on there... but nevermind.

> The path to this file is stored in IMK.path macro.  The 1st 3 lines include
> the common.imk file in the directory just above the one with target.imk. 
> This is useful when you want to store values common to several .imk files
> in upper level directories.

I understand. What values are typically inherited this way? It is planned 
that project properties can be declared and will be also inherited from 
parents. Will such inheriting be enough to achive the same effect? 

- Volodya