Re: [Boost-build] Suppressing auto-detected address-model from paths

Subject: Re: [Boost-build] Suppressing auto-detected address-model from paths
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2015-04-04 15:38:29

AMDG

On 04/04/2015 11:47 AM, Robert Ramey wrote:
> 
> My specific problem is that I invoke the program and I don't know what it
> actually
> is doing.  When things seem to work as I expect, I don't really know what I
> did.
> When things don't seem to work as I expect, I have to spend a lot of time
> tracing through layers of Jam code which I don't understand to figure out
> what to do.
> 

  This isn't specific enough for me to do anything.
To put it bluntly, I can't reproduce your problem,
because I do understand how Boost.Build works, and
therefore, when I invoke it, I do know what it's
actually doing.

  If you can give concrete use cases, I might be
able to do something.

- I can improve the documentation.  This only helps
  if people actually read the documentation.
- I can improve error messages for incorrect usage.
- I'm currently working on a Jam debugger,
  that will hopefully make tracing through
  Jam code easier when it's actually necessary.

> I've always disliked boost build for this reason.  I've followed the efforts
> of the boost build developers with interest and curiosity for many years.
> I always thought they would give up.  So I refrained from making suggestions
> which seemed too ambitious since I didn't want discourage them.  But
> since it seems that they are never giving up (I admire this), I'm going
> to suggest that you take my observations above and think about them
> some more.  I realize that looking at boost build in this way, might seem
> to be too ambitious and maybe it is.  All I'm asking is that you spend
> a little effort thinking about this.  FWIW, the idea that the computer
> program can hide complexity by hiding what it is actually doing is very
> much in vogue today and is the source of lots of problems. 
> 

Boost.Build has options for telling you everything
you could possibly want to know about the decisions
it's making.  Nobody uses them.  Most people don't
even know they exist, even though they're documented.

> Boost build DOES fill a niche that no one else does.  CMake fills a
> different
> and complementary niche.  See my comments on www.bincubator.com
> contrasting these systems.
> 

I'm not sure that I agree with most of your criticism of Boost.Build:

- ...Jamfile.v2 - ....
  Specification of this file requires understand a
  whole new language as well as understanding a large
  range of macro commands...

This applies just as well to every build
system I've ever heard of, including CMake.

- It's not obvious how to use it when building a
  project which is not a member of the boost tree.

I don't understand this at all. If you follow
the instructions right here:
http://www.boost.org/build/doc/html/bbv2/installation.html
there's no dependence on the Boost tree whatsoever.

In Christ,
Steven Watanabe