Re: [Boost-build] modular builds

Subject: Re: [Boost-build] modular builds
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-04 12:33:15

On 04/05/15 12:19 PM, Rene Rivera wrote:
>
>
> On Mon, May 4, 2015 at 11:17 AM, Rene Rivera <grafikrobot_at_[hidden]
> <mailto:grafikrobot_at_[hidden]>> wrote:
>
>     On Mon, May 4, 2015 at 10:50 AM, Stefan Seefeld
>     <stefan_at_[hidden] <mailto:stefan_at_[hidden]>> wrote:
>
>
>         Indeed. Is there a better way to approach this ? If
>         boost.python (as
>         well as most other libraries, I'd assume) depend (at least
>         implicitly)
>         on boostcpp.jam, shouldn't that dependency be made explicit by
>         having
>         another module / component "own" it, such that boost.python
>         can then
>         depend on it ?
>
>         It seems to me that for the last couple of years people have been
>         arguing about modularizing boost with a very narrow focus on
>         things like
>         header dependencies and source tree layouts, when there are
>         many other
>         issues to be resolved.
>         How useful is it to hold individual boost libraries in
>         distinct git
>         repositories, if I still need to check out the entire boost repo
>         including its submodules, to be able to build an individual
>         library ?
>
>
>     Because of some external needs I started on a method to build
>     Boost libraries without needing to do that full checkout. But
>     obviously you would need to git clone the individual repos of all
>     the dependencies.
>

OK. Isn't this similar to a normal boost build with an explicit
--with-<library> argument ?

>     They BB support for this is in
>     <https://github.com/boostorg/build/blob/develop/src/contrib/modular.jam>.
>     Using it looks something like this:
>
>     === Jamroot.jam
>     import modular ;
>     # Adds location to search for /boost/* lib references..
>     modular.add-location libs/boost /boost ;
>     # Adds external (to lib build files) dependency references..
>     modular.external /boost/config : /boost/predef//library ;
>     ===
>     === Jamfile.jam
>     import modular ;
>     exe my_program :  [ glob ../src/*.cpp ] /boost/config//library
>       /boost/system//boost_system ;
>     ===
>
>
> Oops, forgot something in that example:
>
> === Jamfile.jam
> import modular ;
> exe my_program : [ glob ../src/*.cpp ]
>   [ modular.find /boost/config//library ]
>   [ modular.find /boost/system//boost_system ] ;
> ===
>
>     All that it expects (or at least the goal is this) is that you
>     have the needed libs in the search path as specified in the
>     modular.add-location calls. Everything else should be handled.
>     This doesn't currently doesn't handle the Boost tagging names
>     stuff. As my use case only needed direct BB building.
>
>     Does this look like a better direction?
>

This definitely looks interesting, thanks ! In particular, the
"module.external" thing sounds like it might be what I'm looking for.
I'll have to play with it.

On the other hand, what I really want is this:

For all prerequisite libraries:

* provide the means to indicate search paths (header and library)
* add those paths to the compiler / linker flags
* really only build the local library, instead of first trying to build
prerequisites

In other words, I'd like to be able to treat prerequisite boost libs as
normal external dependencies. I'm proposing to do this for boost.python,
which is relatively stable, and thus shouldn't depend on any new
features in its prerequisite libs, so it should be possible to build it
against a wide range of versions of the prerequisite libs, without
(much) concern for compatibility. Once this works, we can let
boost.python follow its own release schedule.

(And if that experiment succeeds, I'm sure other library maintainers may
want to do something similar with their libraries. *That* would bring us
much closer to a "modular boost".)

Thanks,
        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...