Re: [Boost-build] modular builds

Subject: Re: [Boost-build] modular builds
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2015-05-04 12:55:20

On Mon, May 4, 2015 at 11:33 AM, Stefan Seefeld <stefan_at_[hidden]> wrote:

> 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 ?
>

No. I don't have the top-level Boost structure at all in my project. All I
have are the sources for individual libraries that I need and nothing else.
So there's no --with handling to speak of.

>     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.
>

I'm trying to decipher what your goals are. Since I can't see what use case
you are trying to solve. Are you:

1. Trying to support building BPL against an external system provided
regular Boost install?
2. Support building BPL with a full Boost tree checkout?
3. Users building their apps with BPL already built and installed?
4. Something else?

> (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".)
>

I would avoid putting too much effort into this until the use case(s) is
*very* clear. Kludging something together in BB tends to backfire.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail