Geometry Boost List: [ggl] Fixing Boost location in Jamfiles

Subject: [ggl] Fixing Boost location in Jamfiles
From: Barend Gehrels (Barend.Gehrels)
Date: 2010-03-10 03:48:23

Hi Mateusz,

> Barend, to follow up our talk we had on jabber, Volodya explained to
> me the proper way of how to refer to Boost headers in Jamfile of
> programs living outside Boost tree. The trick is to use <source> instead
> of <include> for project in Jamfile.
>
>
> The procedure to configure Boost environment and project Jamfile is:
>
> 1) Set user-config.jam with location of Boost
>
> # For example, this points to my copy of Boost SVN trunk
> use-project boost : D:/dev/boost/_svn/trunk ;
>
> 2) Jamfile of "test" project outside Boost tree
>
> project test
>     : requirements
>     <source>/boost//headers
>     ;
> exe test1 : test1.cpp ;
> exe test2 : test2.cpp ;
>
> It is possible to set it per "exe" target too, this way:
>
> exe test2 : test2.cpp /boost//headers ;
>
>
> This way it looks for headers using absolute location combined this way:
>
> "/boost//headers" is parsed as:
>
> 1) /boost
>
> It means "boost" project location as configured in user-config.jam and
> its location of D:/dev/boost/_svn/trunk
>
> 2) //
>
> The  double forward slash means "Achtung! Now comes named target as
> defined in "boost" project requested by /boost
>
> 3) headers
>
> This is name of target.
>
>
> Another example, if you need "test" library from boost project,
> you can include it by referring to the "boost" project and corresponding
> target, in similar way as above: /boost//test
>   

Thanks for your careful explanation, I will look tonight.

>
> So, if we set the <source>/boost//headers in Jamfiles of tests/examples
> then users will be able to build them having the Boost.Geometry tree
> outside Boost sources tree. I think it's a good idea to allow it
> as it's convenient. I work like that myself having
>
> /path/to/boost/svn/sandbox/geometry
> /path/to/boost/svn/trunk
>
> Once we move the Geometry to Boost tree, we can replace the
> "/boost//headers" with relative paths as other Boost libraries do.
> Specifically, we replace it with: <include>../../..
>   
Yes, but I still don't understand. The exact <include>../../.. is 
already there. All is designed and configured to be taken up into the 
Boost tree... So why should we modify the Jamfiles for Boost.Geometry 
for just one or two months? That sounds inconvenient to me.

But I'm glad to know the "official way" to do this, strange that it is 
not documented (or at least on the first pages). Just glanced through 
the examples in ...\tools\build\v2\example , and no example is using 
Boost! Of course the hello world compiles (it did for me last night), 
but there are no examples there which are using Boost. I thought that 
Boost.Build was made to build Boost... A "hello boost" would be 
convenient...

> By doing that, we will assure that Boost Geometry is always built
> using the same Boost headers with which our library was shipped.
>   
Eehm, Boost.Geometry will normally be shipped with Boost...

> But for now, we could allow to use Boost headers of user's choice,
> using the location defined in user-config.jam.
>
> I hope it makes more sense now :-)
>   
Yes, it makes more sense and thanks for finding it out and spending so 
much time.

Thanks, Barend