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.
> My specific problem is that I invoke the program and I don't know what it actually is doing. When
> 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
> code which I don't understand to figure out what to do.
> I've always disliked boost build for this reason. I've followed the efforts of the boost build
> interest and curiosity for many years.
> I always thought they would give up. So I refrained from making suggestions which seemed too
> since I didn't want discourage them. But since it seems that they are never giving up (I admire
> going to suggest that you take my observations above and think about them some more. I realize
> 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
> 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk