Boost logo

Boost :

Subject: Re: [boost] Why Boost.Build?
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-03-30 04:36:37


 
> Even though I was the one who contributed to the increase of
> end users dealing with BBv2, with the creation of the
> build&install support, I've always been a proponent that having users
> rely on the Boost build setup is a bug. I.e. users should be able
> to drop source code into their own build system without *any* other
> extra effort. And the fact that many Boost libraries can't do that is sad.
>
> So Boost end users should *not* be the primary audience!
>

Actually I must admit it is wrong statement. Why? Because
the libraries may be much more complicated then you think.

Especially when it comes to handling DLL's where you need a special
defines for DLL build.

But this is only 5% of the problem.

If you try for example build boost-system or other relatively
simple libraries that do not have any external dependencies
it is simple.

Now when it comes to iostreams or regex it becomes more complicated
(zlib, bzip2 and icu)

Now lets take few other libraries that are now in review queue:

- Boost.Context - it has platform/compiler conditional assembly sources
  and separate build options to use ucontext or fcontext.

  Do you really think it is possible to give a user sources and say
  compile them?

- Boost.Locale - it depends on several libraries: ICU, iconv and boost-thread
  conditionally has 5 build options (with/out icu,iconv,win32api,posix-api,
  std-locale-api) and some of them should be turned conditionally for different
  platforms.

So no I don't expect user to do all the job for me. This is why build
system exists.

Boost is lucky because its libraries and build are relatively simple.
and before anybody screams about how sophisticated boost is I add

- Almost no compile time configuration (something like generated config.h)
- Almost no 3rd part dependencies.
- Almost all configuration is done by ifdefs instead of configure like
  scripts that can test features automatically and not require from
  user to know every possible OS/Compiler setup.

So that is why Boost.Build suites somehow Boost and in general
this is why build system exist.

A friend of mine that works with MSVC Projects only do not understand
all buzz around makes/cmakes/autotools/bjams and so on because
he writes software for one compiler and one platform... So MSVC projects
suit him.

But in real world Build system is essential part of any project.

> And like Emil says in reply to this also,
> for those of us that use BBv2 the only painful
> drawback is the speed. Which is solvable in many ways.
> One of which, porting to Python, has shown the likely
> speed improvements. To put it another way.. Jam is an OK
> designed scripting base for BBv2.. But bjam is a terrible
> implementation of that design :-)
>

By no way bjam speed is the showstopper. If the only problem
of BBv2 was its speed I was loving it.

Artyom


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk