lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] patch: upgrade to Boost 1.38.0


From: Vaclav Slavik
Subject: Re: [lmi] patch: upgrade to Boost 1.38.0
Date: Fri, 03 Apr 2009 14:32:08 +0200

On Fri, 2009-04-03 at 10:45 +0200, Vadim Zeitlin wrote:
> VS> Ideally, I'd like to rewrite this part of the makefiles to build Boost
> VS> using the official Boost.Build system if you agree -- upgrading is
> VS> easiest that way.
> 
>  Does this mean requiring the use of bjam? 

That's what they use, yes.

> If so I'd personally really like to avoid it: not only because I
> dislike bjam personally (I know it must be
> my own fault but I have difficult to debug problems with it all the time)
> but also because it seems a bad idea to mix several make tools in the build
> process of one project, it's just confusing.

I agree it's a bad idea _in_ one project's build system, but Boost is
just a dependency. It is built once, as part of setup process for
building LMI and is on the same level as installation of MinGW toolchain
in install_msw.sh. It isn't integrated in LMI's build system; in
particular, if you touch a Boost source file, nothing gets rebuilt.

Also note that if you look at it this way, LMI already mixes two
different build systems: LMI itself is built with GNU Make, but some of
its dependencies (libxml2, libxslt and now xmlwrapp) use Autotools.

>  Of course, if the advantages of using it are important enough to outweigh
> these (perceived) disadvantages, so be it. But I wonder what exactly these
> advantages are, could you please explain, if only briefly?

a) Upgrading to newer versions of Boost is easier (see
http://lists.nongnu.org/archive/html/lmi/2008-06/msg00054.html for the
kind of problems you get when you don't use the "official" upstream
build system and look at the date it was written).

b) Adding a dependency on a new Boost library that isn't headers-only is
easier.

Both of these are because we don't have to waste time and effort on
maintaining makefiles for Boost if we use upstream's build system. I
dislike Boost.Build as much as the next person (even though it is
incomparably better than raw jam), but I dislike duplicating upstream's
work on makefiles even more.

Regards,
Vaclav





reply via email to

[Prev in Thread] Current Thread [Next in Thread]