Suppressing auto-detected address-model from paths

[Vladimir Prus-4]

Hi,

since recently, Boost's root Jamfile autodetects address model (as well as architecture). That's nice
for libraries that need to know address model in all cases, but it also adds an extra element to
target paths in all cases.

I was thinking about best way to avoid it. Conceptually, we have a number of toolset instances -
combinations of toolset name and exact commands, and for each such toolset instance, we can determine
default address-model. Then, if we have a property set which address-model property equal to toolset instance
default, we don't need it in path. That maps fairly clearly to features:

- Introduce toolset-instance feature that is always set, to some opaque identifier
- Make it composite, and include appropriate address-model= among the components.

That would suppress unnecessary address-model elements due to way we handle composite features already.
The only slight issues is that toolset-instance property - it would be actually nice to give ids
to each 'using', and make sure we always pick one of those, but it's a bit of work. While I have
some code for that in Python version, it works only for gcc and rather lightly tested.

So the attached patch implements a stop-gap approach. It adds a new composite property
representing deduced address model as well as 'hidden' attribute for features. So, if we have

        <deduced-address-model>64 <address-model>64

then the latter is consumed by the former, and the former is hidden from the path. If we have

        <deduced-address-model>64 <address-model>32

which would only be possible if some target specifically specify 32-bit, then we'd hide the former
property, while the latter will be visible.

The same approach should work for architecture. Comments? Is it good for upcoming release?


--
Vladimir Prus
http://vladimirprus.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Robert Ramey]

Vladimir

Auto detection creates a lot of problems for me when I used boost build.  Often it seems that boost build does what I need - which  would be OK but it doesn't tell me that.  So sometimes it's doing something other than what I think it is.

Take address model - for my platform it might be 64.  I have a old PC I use for testing - the correct model on that platform is 32.  Now if I run the exact same test script on both machines I get different results and don't know why - unless I trace into Jam code which is not what I want to do. There are other example link=shared/static etc.

This problem is compounded by the usage of user-config and project-config files which may contain settings which I don't know about and which vary according to the compiler being used.

There may be some switch which displays all these "autoselections" in the log which would be useful.  I know I've spent a lot of time chasing down these kinds of problems and haven't found a magic switch - but maybe I just never looked in the right place.

A few ideas which might be helpful.

a) Display all the "feature switches" (I don't know the jam jargon but I mean things like linik= address-model= ...) at the top of the log.  A switch (-q) could be provide for those who don't need this information.

b) or a switch (-nq) which outputs all the above.

c) when I specify something that doesn't make sense - it seems that b2 just fixes it up and "makes it right".  But now I'm back where I was not knowing that I was doing something wrong and likely getting something that is different than what I thought I was asking for.  I would prefer that the program just stop immediately with and error message telling me what I did wrong.  Of course others might now like that - so it could be conditions on -fixup or -nofixup.

To me, these changes would go a long way toward making b2 easier to use.  Also I think it might make your life easier.  If everything someone asks a question about why it b2 doesn't produce what they expect - that is doesn't work, you tweaked the jam files so that it implement the above, that would be the last time you'd have to deal with that question.  Thus the time spent dealing with "support" would exponentially taper off toward zero.

Robert Ramey

[Steven Watanabe-4]

AMDG

On 04/03/2015 01:48 PM, Vladimir Prus wrote:

>
> So the attached patch implements a stop-gap approach. It adds a new
> composite property
> representing deduced address model as well as 'hidden' attribute for
> features. So, if we have
>
>     <deduced-address-model>64 <address-model>64
>
> then the latter is consumed by the former, and the former is hidden from
> the path. If we have
>
>     <deduced-address-model>64 <address-model>32
>
> which would only be possible if some target specifically specify 32-bit,
> then we'd hide the former
> property, while the latter will be visible.
>
> The same approach should work for architecture. Comments? Is it good for
> upcoming release?
>

I like it.  The only issue I have is that
<deduced-address-model> propagates across
a toolset change, which could result in
strange behavior.  I think it should work
well enough to get this release out, however.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Steven Watanabe-4]

AMDG

On 04/03/2015 02:11 PM, Robert Ramey wrote:
>
> Auto detection creates a lot of problems for me when I used boost build.
> Often it seems that boost build does what I need - which  would be OK but it
> doesn't tell me that.  So sometimes it's doing something other than what I
> think it is.
>

<snip>

All this is possibly useful, but not relevant
to the problem at hand.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Steven Watanabe-4]

AMDG

On 04/03/2015 02:11 PM, Robert Ramey wrote:
>
> a) Display all the "feature switches" (I don't know the jam jargon but I
> mean things like linik= address-model= ...) at the top of the log.  A switch
> (-q) could be provide for those who don't need this information.
>

This isn't really possible because this information
is determined on a per-target basis.  e.g. it's
perfectly fine to build both static and shared
libraries at the same time.

> b) or a switch (-nq) which outputs all the above.
>

It's called --debug-building, which outputs
the properties used to build each target.
You may not like the volume of output, though.

> c) when I specify something that doesn't make sense - it seems that b2 just
> fixes it up and "makes it right".

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

>  But now I'm back where I was not knowing
> that I was doing something wrong and likely getting something that is
> different than what I thought I was asking for.  I would prefer that the
> program just stop immediately with and error message telling me what I did
> wrong.  Of course others might now like that - so it could be conditions on
> -fixup or -nofixup.
>

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Steven Watanabe-4]

AMDG

On 04/03/2015 01:48 PM, Vladimir Prus wrote:

>
> So the attached patch implements a stop-gap approach. It adds a new
> composite property
> representing deduced address model as well as 'hidden' attribute for
> features. So, if we have
>
>     <deduced-address-model>64 <address-model>64
>
> then the latter is consumed by the former, and the former is hidden from
> the path. If we have
> <snip>
> Comments? Is it good for
> upcoming release?
>

<deduced-address-model> should not depend on
a user specified <address-model>.  It should
only depend on the compiler default.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Vladimir Prus-4]

On 04/04/2015 12:19 AM, Steven Watanabe wrote:

> AMDG
>
> On 04/03/2015 01:48 PM, Vladimir Prus wrote:
>>
>> So the attached patch implements a stop-gap approach. It adds a new
>> composite property
>> representing deduced address model as well as 'hidden' attribute for
>> features. So, if we have
>>
>>      <deduced-address-model>64 <address-model>64
>>
>> then the latter is consumed by the former, and the former is hidden from
>> the path. If we have
>> <snip>
>> Comments? Is it good for
>> upcoming release?
>>
>
> <deduced-address-model> should not depend on
> a user specified <address-model>.  It should
> only depend on the compiler default.

Yes, I woke up with exactly same conclusion today. With the original patch, explicitly specifying
address-model=64 on the command line will add a path element even if compiler default is also 64-bit.

The attached boost.diff handles it. However, it requires a further change to build, also attached.
Right now, when indirect conditional returns a composite property, its constituents override any
existing properties. In case of deduce-address-model, we want it to be expanded, but not override
any value of address-model that is already specified.

In future, we'll probably have custom code to select toolchain and then determine these
properties, but for now, the only way I could think of was to change expansion of result
of indirect conditional to do what we want for address-model. It's quite possible
than existing code will be affected, but it will be easy to fix via explicit feature.expand
call. Comments?


--
Vladimir Prus
http://vladimirprus.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Vladimir Prus-4]

Robert,

On 04/03/2015 11:11 PM, Robert Ramey wrote:

> a) Display all the "feature switches" (I don't know the jam jargon but I
> mean things like linik= address-model= ...) at the top of the log.  A switch
> (-q) could be provide for those who don't need this information.

The prototype at

        http://vladimirprus.com/talks/boosting-cdt-builds/demo/

attempts to do so. However, it's probably only possible as part of UI, as Steven
mentioned properties are often different for different targets, and the volume
of output is quite large to analyze in form of a txt file.


--
Vladimir Prus
http://vladimirprus.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Steven Watanabe-4]

AMDG

On 04/04/2015 05:19 AM, Vladimir Prus wrote:

>
> Yes, I woke up with exactly same conclusion today. With the original
> patch, explicitly specifying
> address-model=64 on the command line will add a path element even if
> compiler default is also 64-bit.
>
> The attached boost.diff handles it. However, it requires a further
> change to build, also attached.
> Right now, when indirect conditional returns a composite property, its
> constituents override any
> existing properties. In case of deduce-address-model, we want it to be
> expanded, but not override
> any value of address-model that is already specified.
>

Couldn't we fix this by including the given
address-model in the result if it's already
specified?  I'd really like to avoid potentially
breaking changes to Boost.Build this late
in the release cycle.

> In future, we'll probably have custom code to select toolchain and then
> determine these
> properties, but for now, the only way I could think of was to change
> expansion of result
> of indirect conditional to do what we want for address-model. It's quite
> possible
> than existing code will be affected, but it will be easy to fix via
> explicit feature.expand
> call. Comments?
>

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Vladimir Prus-4]

On 04/04/2015 05:36 PM, Steven Watanabe wrote:

> AMDG
>
> On 04/04/2015 05:19 AM, Vladimir Prus wrote:
>>
>> Yes, I woke up with exactly same conclusion today. With the original
>> patch, explicitly specifying
>> address-model=64 on the command line will add a path element even if
>> compiler default is also 64-bit.
>>
>> The attached boost.diff handles it. However, it requires a further
>> change to build, also attached.
>> Right now, when indirect conditional returns a composite property, its
>> constituents override any
>> existing properties. In case of deduce-address-model, we want it to be
>> expanded, but not override
>> any value of address-model that is already specified.
>>
>
> Couldn't we fix this by including the given
> address-model in the result if it's already
> specified?  I'd really like to avoid potentially
> breaking changes to Boost.Build this late
> in the release cycle.

Fair enough. Here's what I've checked in:

     https://github.com/boostorg/boost/commit/945e3c0bbdd31ce8c297e0aff5340f0adb196cea

Seems to work fine in all testing.

--
Vladimir Prus
http://vladimirprus.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Robert Ramey]

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

[Steven Watanabe-4]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[pabristow]

> -----Original Message-----
> From: Robert Ramey [mailto:[hidden email]]
> Sent: 04 April 2015 18:48
> To: [hidden email]
> 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







_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Steven Watanabe-4]

AMDG

On 04/06/2015 10:29 AM, Paul A. Bristow wrote:

>
>> -----Original Message-----
>> From: Robert Ramey [mailto:[hidden email]]
>>
>> 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,

If you mean that the b2 command line should be echoed,
I don't think that's a good idea, as this information
is trivially available to the caller already.  If you
mean the updating command, it's printed by default
only when it fails.  Please keep in mind that adding
more output makes it harder to find the information
that you actually care about.

> how many failed, how many succeeded...
>

???

...failed updating 2 targets...
...skipped 6 targets...
...updated 80 targets...

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

Well, there's not much Boost.Build can do about this, is there?

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

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Robert Ramey]

Steven Watanabe-4 wrote

Well, there's not much Boost.Build can do about this, is there?

I get from your response that you feel you've done all that is reasonable
to do to make this easier for the rest of us.  And that if we're having
problems, we're just not working hard enough or need to be doing
something differently.

I think you should approach these suggestions from a different view point.

Start with the premise that any build tool should be easy and obvious to
use to get some desired result and hard to mis-use for the average
person who can write a C++ program.  Anytime such a user has difficulty
make the tool do what he wants it has to be considered as some type
of program and/or design bug and should be addressed as such.  After
addressing things this way, complaints will taper off exponentially.  That
is the time between complaints will increase linearly.

Of course this seems impossible.  But it's not.

There are well known sources of surprising behavior.  "global variable"
like in user-config, side effects like when I set one feature it "knows"
that some other feature needs to be set.  Default behavior like naming
of output libraries - which is done silently.  One giant global variable whose
effect is not transparent is the current directory from which b2 is invoked.
These "environments" should be listed when b2 starts unless a -q switch
is included.

At this point, it's too hard to go back and redesign everything.  But what
you can do is something like the following.

a) User has a complaint.  This takes the form like "I can't build with gcc
on Mac OS - it gives me an error which I don't understand".

b) current method - respond to the user's complaint with "Try using
toolset darwin rather than gcc".  Problem solved -  NOT.  It's not fixed
it's just going to come up again.

c) The source of the problem is that the error message doesn't tell the
user what to do.  So he has to email in and to get a response.  The fix
for this is to tweak something somewhere so that the error message
says something like:

"GCC toolset doesn't work on MACOS - try using darwin instead"
and have b2 abort.  

This wouldn't entail fiddling with b2 source code.  I'm guessing that
the just tweaking the gcc and/or darwin toolset would do the job.
That one simple change would quash this particular problem
forever.

Of course the above are examples and might not be exactly correct.
But I think one could find his own.

So the problem isn't b2  - it works (or can be made to work).  It's
not badly documented (thought I'm thinking some information on
toolsets is out of date).  It's that you're thinking since the above is
true you're done.  That is not true.  I think you'd be more successful
if you stepped backed and examined your criteria for success and
shifted it from having a correct, documented and useful software tool
to a tool that moderately competent programmers can use with to get the results
he desires without major frustration.

I pains me to see you guys working so hard and not having
your "customers" as happy as I think they should and can be.

Robert Ramey

[Steven Watanabe-4]

AMDG

On 04/06/2015 11:52 AM, Robert Ramey wrote:
> Steven Watanabe-4 wrote
>> Well, there's not much Boost.Build can do about this, is there?
>
> I get from your response that you feel you've done all that is reasonable
> to do to make this easier for the rest of us.

In some cases, yes.  I can't think of anything
I can possibly change to alleviate the particular
complaint that I was responding to in any way.

>  And that if we're having
> problems, we're just not working hard enough or need to be doing
> something differently.
>
> I think you should approach these suggestions from a different view point.
>
> Start with the premise that any build tool should be easy and obvious to
> use to get some desired result and hard to mis-use for the average
> person who can write a C++ program.  Anytime such a user has difficulty
> make the tool do what he wants it has to be considered as some type
> of program and/or design bug and should be addressed as such.  After
> addressing things this way, complaints will taper off exponentially.  That
> is the time between complaints will increase linearly.
>
> Of course this seems impossible.  But it's not.
>

This doesn't take into account the fact that
fixing one such problem can exacerbate other
problems.

> There are well known sources of surprising behavior.  "global variable"
> like in user-config,

What surprising behavior is caused by
the fact that user-config.jam is global?

> side effects like when I set one feature it "knows"
> that some other feature needs to be set.

I don't know what you're talking about.
In fact, I've heard a lot more complaints,
that Boost.Build /doesn't/ set features,
which "obviously" ought to be set automatically.

>  Default behavior like naming
> of output libraries - which is done silently.

This isn't Boost.Build per se.
Library naming is controlled
by Boost's top-level Jamroot.

>  One giant global variable
> whose
> effect is not transparent is the current directory from which b2 is invoked.

The only place I know of where the
current working directory matters is
for building documentation.  I consider
this a bug in doc toolchain.

> These "environments" should be listed when b2 starts unless a -q switch
> is included.
>

It can't be -q, because -q already means something else.
I'm very reluctant to make the output more verbose
by default.  I see plenty of issues where I can
make the problem completely obvious, simply by
trimming the error message.

> At this point, it's too hard to go back and redesign everything.  But what
> you can do is something like the following.
>
> a) User has a complaint.  This takes the form like "I can't build with gcc
> on Mac OS - it gives me an error which I don't understand".
>
> b) current method - respond to the user's complaint with "Try using
> toolset darwin rather than gcc".  Problem solved -  NOT.  It's not fixed
> it's just going to come up again.
>
> c) The source of the problem is that the error message doesn't tell the
> user what to do.  So he has to email in and to get a response.  The fix
> for this is to tweak something somewhere so that the error message
> says something like:
>
> "GCC toolset doesn't work on MACOS - try using darwin instead"
> and have b2 abort.  
>

I'm somewhat hesitant to suggest fixes in error message.
- If we can be certain that the fix is correct,
  then there's surely a way to make sure that
  the problem can't happen in the first place.
- If the suggestion is not what the user intends,
  it's going to cause even more confusion.

> This wouldn't entail fiddling with b2 source code.

Very few things do.

>  I'm guessing that
> the just tweaking the gcc and/or darwin toolset would do the job.
> That one simple change would quash this particular problem
> forever.
>

It would help some, but I don't agree that it would
eliminate the problem entirely.  I don't believe that
there should be a darwin toolset in the first place.
Also, this particular problem hasn't been hasn't been
nearly as much of an issue since the default toolset was
fixed to be darwin.  I do agree that there should
be better checking when initializing a toolset.

> Of course the above are examples and might not be exactly correct.
> But I think one could find his own.
>
> So the problem isn't b2  - it works (or can be made to work).  It's
> not badly documented (thought I'm thinking some information on
> toolsets is out of date).  It's that you're thinking since the above is
> true you're done.  That is not true.  I think you'd be more successful
> if you stepped backed and examined your criteria for success and
> shifted it from having a correct, documented and useful software tool
> to a tool that moderately competent programmers can use with to get the
> results
> he desires without major frustration.
>
> I pains me to see you guys working so hard and not having
> your "customers" as happy as I think they should and can be.
>

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Robert Ramey]

Steven Watanabe-4 wrote

This doesn't take into account the fact that
fixing one such problem can exacerbate other
problems.

LOL - sure it does.  The objective is "Kaizan" - continuous improvement.
Obviously fixing one problem to create another doesn't qualify.

> There are well known sources of surprising behavior.  "global variable"
> like in user-config,

What surprising behavior is caused by
the fact that user-config.jam is global?

Not that user-config.jam is global, but that it alters global settings such
as compiler switches.  I understand the apeal of doing this and if you have
to do it, you should not make it "silent" as it is now.  It should some how
report these so that if the change when I'm not looking, I get a heads up.

I may set some compiler switches in user-config and forget that I did so.
Or I might change my environment, or run a different compiler as a test.
The functioning of b2 (BTW and lots of other programs) may change
with me having idea what the source of the change is.  Its exactly
analogous to the problem of global variables in a C++ program -
and creates the exact same type of problems.

> side effects like when I set one feature it "knows"
> that some other feature needs to be set.

I don't know what you're talking about.
In fact, I've heard a lot more complaints,
that Boost.Build /doesn't/ set features,
which "obviously" ought to be set automatically.

I'm sure you have.  I'm arguing that these suggestions are mis-guided
and the attempts to implement this point of view make the program
harder to use and easier to mis-use.

>  Default behavior like naming
> of output libraries - which is done silently.

This isn't Boost.Build per se.
Library naming is controlled
by Boost's top-level Jamroot.

My mistake, I thought the library name and location was determined by
the toolset, auto link variables, stage and other command line switches
in the b2 command line (BTW which is right place so this works for me).

>  One giant global variable
> whose
> effect is not transparent is the current directory from which b2 is invoked.

The only place I know of where the
current working directory matters is
for building documentation.  I consider
this a bug in doc toolchain.

well, on my machine if I invoke b2 from the directory
boost_root/libs/serialization/test I get build and run of the tests of the
serialization library (after building it's pre-requesites)  While if I run it from boost
root I get something quite different - all the libraries built.  And this is with
exactly the same command line !  So the current directory has a lot to do
with what's going to happen when you invoke b2.  If the current directory
doesn't have a jamfile.v2 , It seems its going to search the directory hierarchy
using some rule that I forget.  Any it's more behavior which one
can't anticipate with spending a lot of time investigating before
he actually launches the command.

<
> These "environments" should be listed when b2 starts unless a -q switch
> is included.
>
It can't be -q, because -q already means something else.

LOL - pick another switch then.

I'm very reluctant to make the output more verbose
by default.  I see plenty of issues where I can
make the problem completely obvious, simply by
trimming the error message.

> "GCC toolset doesn't work on MACOS - try using darwin instead"
> and have b2 abort.  

I'm somewhat hesitant to suggest fixes in error message.

LOL - give me a break - it's an example off the top of my head

- If we can be certain that the fix is correct,
  then there's surely a way to make sure that
  the problem can't happen in the first place.

THIS is the fundamental mistake !!!   In many or most cases I'm talking
about there is no way you can automatically fix it because you have no
way of reading my mind.  If I say "b2" you can't decide for me without
asking what I want.  If I go to 31 flavors icecream as ask for an
icecream cone - what's going to happen? Is the guy going to just
take a look at me say - that guy is 67 years old - they usually order
pistachio so that's what I'll assume he want's.  NOOO he's going to
ask "what flavor" and abort the operation until I try again.

- If the suggestion is not what the user intends,
  it's going to cause even more confusion.

The above is an example.  If you can think of something better fine.  The
point is that the current situation costs a naive user such as myself
a lot of time and frustration.  If you can find a way to diminish this b2
will be more widely appreciated and used.

>  I'm guessing that
> the just tweaking the gcc and/or darwin toolset would do the job.
> That one simple change would quash this particular problem
> forever.

It would help some, but I don't agree that it would
eliminate the problem entirely.

And??? what's wrong with making an improvement?

 I don't believe that
there should be a darwin toolset in the first place.

An even better fix !!! - You're getting it !!!

Also, this particular problem hasn't been hasn't been
nearly as much of an issue since the default toolset was
fixed to be darwin.  I do agree that there should
be better checking when initializing a toolset.

Note that I'm not complaining about this or that particular issue
but the whole way of looking at what the task is.

Robert Ramey

[Steven Watanabe-4]

AMDG

On 04/06/2015 05:01 PM, Robert Ramey wrote:
>
> Note that I'm not complaining about this or that particular issue
> but the whole way of looking at what the task is.
>

  I'd much rather that you complained about
particular issues.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Steven Watanabe-4]

AMDG

On 04/06/2015 05:01 PM, Robert Ramey wrote:
> Steven Watanabe-4 wrote
>> This doesn't take into account the fact that
>> fixing one such problem can exacerbate other
>> problems.
>
> LOL - sure it does.  The objective is "Kaizan" - continuous improvement.
> Obviously fixing one problem to create another doesn't qualify.
>

Would you mind explaining how to create
automated regression tests for ease of use
and lack of surprises?

>>> There are well known sources of surprising behavior.  "global variable"
>>> like in user-config,
>>
>> What surprising behavior is caused by
>> the fact that user-config.jam is global?
>
> Not that user-config.jam is global, but that it alters global settings such
> as compiler switches.  I understand the apeal of doing this and if you have
> to do it, you should not make it "silent" as it is now.  It should some how
> report these so that if the change when I'm not looking, I get a heads up.
>

Are you going to read these messages
every time you run b2?  I'm not
denying that this information is
occasionally useful, but I'm far from
convinced that it's important enough
to be worth printing automatically on
every run.

> <snip>
>
>>> side effects like when I set one feature it "knows"
>>> that some other feature needs to be set.
>>
>> I don't know what you're talking about.
>> In fact, I've heard a lot more complaints,
>> that Boost.Build /doesn't/ set features,
>> which "obviously" ought to be set automatically.
>
> I'm sure you have.  I'm arguing that these suggestions are mis-guided
> and the attempts to implement this point of view make the program
> harder to use and easier to mis-use.
>

I really have no idea where you're coming
from here, as your statements are too general.
In the case of architecture/address-model,
which has been one of the main instances
of this, I don't consider setting them
automatically to be wrong.
a) If the user sets them explicitly, this
   setting must be respected.
b) If they are not set, then they will be
   be set to match the compiler's default.

From the point of view of someone running
b2, this automatic setting makes no difference.
It's impossible to build a program for an
unspecified architecture, so the only result
of leaving these features unset is that the
compiler makes the choice, instead.

For someone writing a jamfile, on the other
hand, the difference is clearly positive.
Before, architecture may or may not be present,
and could not be used reliably to change
the implementation.  (e.g. choosing the
right assembler file for Boost.Context).

> <snip>
> well, on my machine if I invoke b2 from the directory
> boost_root/libs/serialization/test I get build and run of the tests of the
> serialization library (after building it's pre-requesites)  While if I run
> it from boost
> root I get something quite different - all the libraries built.  And this is
> with
> exactly the same command line !  So the current directory has a lot to do
> with what's going to happen when you invoke b2.

I didn't even consider that this might be
what you were referring to.  Using the
build script in the current directory is
pretty much standard practice for all build
systems starting with make.  I really don't
see how printing the cwd is useful to anyone.
Even if you ran
$ b2 .
or
$ b2 libs/serialization/test
it would still be affected by the current
working directory.

>  If the current directory
> doesn't have a jamfile.v2 , It seems its going to search the directory
> hierarchy
> using some rule that I forget.

It doesn't.  It issues an immediate error
if there's no jamfile in the current directory.

>  Any it's more behavior which one
> can't anticipate with spending a lot of time investigating before
> he actually launches the command.
> <snip>
>>> "GCC toolset doesn't work on MACOS - try using darwin instead"
>>> and have b2 abort.  
>>
>> I'm somewhat hesitant to suggest fixes in error message.
>
> LOL - give me a break - it's an example off the top of my head
>
>> - If we can be certain that the fix is correct,
>>   then there's surely a way to make sure that
>>   the problem can't happen in the first place.
>
> THIS is the fundamental mistake !!!   In many or most cases I'm talking
> about there is no way you can automatically fix it because you have no
> way of reading my mind.  <snip>
>

Which naturally lands us on the other
horn of the dilemma:

>> - If the suggestion is not what the user intends,
>>   it's going to cause even more confusion.
>

And the worst part is:
- If we just say what's wrong without a fix,
  (possibly even if we do) it will almost
  certainly get chalked up as another
  incomprehensible b2 error.

I know that we need better error handling, but
it's not going to magically solve all our troubles.
Writing good error messages ranges from hard to
impossible.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[Robert Ramey]

Steven Watanabe-4 wrote

> Note that I'm not complaining about this or that particular issue
> but the whole way of looking at what the task is.

I'd much rather that you complained about particular issues.

I'm complaining about the way you address particular issues.  I think
if you step back a little and look at from a user perspective, you'll
be more successful.  I realize that I've failed to convince you that
things could be improved if you did this so I'll let you get back
to work. Maybe this discussion might trigger some ideas next
time you need to address some particular complaint.  Good luck
with boost build!

Good luck with this.

Robert Ramey