Re: [boost] [ot] choosing a build system

Subject: Re: [boost] [ot] choosing a build system
From: Sergey Popov (loonycyborg_at_[hidden])
Date: 2012-05-16 06:14:15

On Tue, 15 May 2012 06:40:10 -0600
Dave Abrahams <dave_at_[hidden]> wrote:

> Because it's not a problem in practice, I don't consider it to be a
> high priority.
I've found these features useful and don't wish to forfeit them to
someone else's design mistakes.

> 
> >> > Also, the extra step is simply annoying. 
> >> 
> >> Matter of taste, I guess.  It annoys me that Boost.Build does a
> >> configure every single time I build.
> >
> > There's no such thing as 'configure'. It just doesn't exist. 
> 
> It certainly does exist.  I wrote a lot of configure code for
> Boost.Build myself.
This nonsensical 'configure' abstraction should go. It only makes build
scripts more complex. External dependencies are in fact parts of
dependency graph and have no business being segregated into a separate
linear script. If you have them in DAG you e.g. won't have to go through
C++ checks if you only want documentation to be generated or some
other utility task performed. If you'll try to implement that in a
linear script you'll just get a bunch of unmaintainable if statements
which build tools like Make are supposed to prevent in the first place.

> >> > It doesn't matter that you can hide it with scripts and what-not.
> >> > It's still there, making your life harder and the overall system
> >> > more complex. 
> >> 
> >> Seems to simplify things from my POV.  Separation of concerns and
> >> all that.
> >
> > Nope. This particular separation happens to be fake. 
> 
> Not true.  For example, use a Ninja backend with CMake instead of a
> Make backend: instant speedup!  It tells you there's nothing to build
> in an already-built Boost tree in < 1s on a weak laptop.  That
> wouldn't be possible if the low-level build engine were not a
> separate component.
This merely seems to fix the problem cmake itself caused. Irrelevant.
> 
> > Besides, no sane modern software system's communications are based
> > on generating files for each other. 
> 
> So you don't use C++ compilers, I guess.
I use -pipe :P
Besides, fixing a build tool is a lot easier than whole goddamn
C/C++ toolchain. I wouldn't say that C++ compilers are exactly sane
considering you have to use an expert system to build almost any
non-trivial program. And the expert system itself is in no obligation
to mimic compiler's ways, considering that it can be easily avoided.

> 
> > They prefer using apis, either by linking directly or via D-Bus or
> > something. Generating (Make)files is just a hack.
> 
> It may not be pure, but it works.
The same can be said about Autotools.
Do not delude yourself thinking that there exists a dichotomy between
purity and practicality. You aim for purity to make the simplest system
that accomplishes the task at hand, and there's nothing more practical
than that. And making Rube Goldberg machines built from false
abstractions is antithesis of practicality.