|
Boost-Build : |
Subject: Re: [Boost-build] Suppressing auto-detected address-model from paths
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-04-04 13:47:56
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.
> It sounds like the specific
> problem that you're complaining about
> here is that target/project properties
> override the command line. This behavior
> is absolutely necessary in some cases.
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.
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. CMake fills a
different
and complementary niche. See my comments on www.bincubator.com
contrasting these systems.
As to the number of target configurations I don't see a huge obstacle here.
As I write this, in the background on my machine I'm running the following
toolset=darwin-4.9,clang-11 variant=debug,release link=static,shared
address-model=64,32
This is probably a lot more than others do and as far as I can it's only
2x2x2x2x = 16 combinations
which is a manageable number. In my test setup this builds and runs on the
order of 1000
executables. This is not a problem for me as I use my library_status tool
to display
the whole (giant) table.
Again, I admire your dedication to this project over the years and I'm sorry
I didn't
find the time to articulate my complaints earlier.
Robert Ramey
-- View this message in context: http://boost.2283326.n4.nabble.com/Suppressing-auto-detected-address-model-from-paths-tp4674095p4674126.html Sent from the Boost - Build mailing list archive at Nabble.com.
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