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

Subject: Re: [Boost-build] Suppressing auto-detected address-model from paths
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-04-06 12:29:34

> -----Original Message-----
> From: Robert Ramey [mailto:ramey_at_[hidden]]
> Sent: 04 April 2015 18:48
> To: boost-build_at_[hidden]
> Subject: Re: [Boost-build] Suppressing auto-detected address-model from paths
> 
> Steven Watanabe-4 wrote
> > This isn't exactly our intention.
> > Properties in Boost.Build can come
> > from many different sources, and
> > we have rules to specify how they're
> > merged.
> 
> I get this.  And I think this is the fundamental difficulty with working with Boost Build.

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

+1

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

+1

> 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 DOES fill a niche that no one else does.  

When it works, it's excellent.

But I use it too rarely to understand it properly, so I inwardly (or sometimes outwardly) groan when
faced with using bjam.

I feel that it would be better to produce a small subset of a dozen popular scenarios and give the
command line for those.

Adding even more info to the log output would also help, including the command used, how many
failed, how many succeeded...

(It's also a bit annoying to find that *all compiles* have failed while you were having lunch, done
the ironing ...)

And an explanation of popular error messages would save time (Googling often produces thousands of
hits).

Paul