Re: [boost] Newbie: How do I handle this directory structure?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-11 12:00:06

----- Original Message -----
From: "Patrick Frants" <patrick_at_[hidden]>

> Hi,
>
> I have looked at JAM in the past, but did not really need it
> then. We are now going to port our products to multiple
> platforms and I suspect that boost can handle both our
> directory structure and other requirements gracefully. The
> problem is that I am not a JAM/boost pro. So maybe some of you
> guys can show me the right direction
>
> The goals are:

> 1. Use as few jamfiles as possible (I suspect the directory
>    structure should allow this)

With Boost.Build, you use one Jamfile per subproject. Of course,
there is no requirement to create multiple subprojects; you could
just refer to all files in your source tree via paths relative to
the project root. The only serious restriction is that built
targets named in a single Jamfile must have distinct names.

> 2. No intermediate libraries, because all C++ static objects
>    need to be initialized at startup

I'm not sure what this means. Could you elaborate? Intermediate
statically-linked libraries, at least, don't normally interfere
with static initialization.

> 3. No need to write out dependencies at the lowest level
>    (MinorProject to individual .cpp files)

I really have no clue what this one means.

> 4. Separate intermediate files from source tree with
>    ALL_LOCATE_TARGET

Done ;-).

> We have this directory structure:
>
>
> Root
> MajorProject1
> MinorProject11
> MinorProject11File1.cpp
> MinorProject11File2.cpp
> MinorProject11File3.cpp
> ...
> MinorProject12
> MinorProject12File1.cpp
> MinorProject12File2.cpp
> MinorProject12File3.cpp
> ...
> MinorProject13
> MinorProject13File1.cpp
> MinorProject13File2.cpp
> MinorProject13File3.cpp
> ...
> ...
> MajorProject2
> MinorProject21
> MinorProject21File1.cpp
> MinorProject21File2.cpp
> MinorProject21File3.cpp
> ...
> MinorSubProjec212
> MinorProject22File1.cpp
> MinorProject22File2.cpp
> MinorProject22File3.cpp
> ...
> MinorProject23
> MinorProject23File1.cpp
> MinorProject23File2.cpp
> MinorProject23File3.cpp
> ...
> ...
> ...
> Executable1 # depends on MajorProject2, MajorProject7 and
Executable1MainFile.cpp
> Executable1MainFile.cpp
> Executable2 # depends on MajorProject6, MajorProject8 and
Executable2MainFile.cpp
> Executable1MainFile.cpp
> ...

Are you saying that minor projects have exactly 3 source files?

> Executables depend on a number of MajorProjects and a specific
> ExecutablNMainFile.cpp. Each MajorProject can be used by
> multiple Executables.
>
> The separation of MajorProjects into MinorProjects is a logical
> separation only.
>
> I was thinking of a kind of jamfile at the MajorProject level
> that is generic. It makes that pseudotarget MajorProjectN
> automatically dependent on all the .cpp files in it's
> MinorProjects (*/*.cpp).

That would work fine if you use static libraries for the minor
projects. If you want to be able to create pseudotargets that
correspond to groups of object files, you'll have to define your
own target type (examples of that can be found in the Jamfiles in
boost's status and libs/python/build directories). There may also
be some build system hacking needed; I'm not sure.

I may be able to address this for you, since I am currently
re-starting my work on the build system... but there's a lot to
do first, so if you can make progress on your own, that would be
much better for both of us ;-).

> Also I would like to have a toplevel jamfile like:
>
> subinclude Executable1 ;
> subinclude Executable2 ;
>
> And in the jamfile in the Executable1 directory:
>
> DEPENDS Executable1 : Executable1MainFile.cpp MajorProject2 MajorProject7
;

I don't think you want the DEPENDS rule here. You'll need more
than that to generate proper build instructions. Probably the
"exe" rule is the right one for you.

> And in the jamfile in the Executable2 directory:
>
> DEPENDS Executable2 : Executable2MainFile.cpp MajorProject6 MajorProject8
;
>
> Is this possible? If not, is there another way to reach the
> same goals?

I think your goals are reachable. I even see that they are not so
esoteric: builders of dynamic libraries who want to ship a single
unified DLL instead of many separate ones might need this,
because apparently it doesn't work to link static libraries with
exported symbols into a dynamic lib on all platforms.

Probably, you'd have to learn a bit more about how the build
system works to accomplish it, though.

HTH,
Dave