Re: [jamboost] Re: Re: thoughts and comments on bjam/Boost.Build V2

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-02-05 04:57:21

Samuel Krempp wrote:

> > I think we wanted to move away from using variable to specify things
> > anywhere.
>
> but this syntax makes the toolset look like a target, would it be possible
> to change it to something more explicit ?
> in the style of : bjam <toolset>gcc
> or whatever explicit syntax.

You can write

bjam toolset=gcc

if you wish.

> > Hmm... is "gcc" above really confusing. I recall someone gave position
> > opinion of this very syntax.
>
> at this stage, no, "gcc" is not really confusing.
> but I know from experience that I get suspicious of any tool that treats a
> parameter differently when it belongs to some subset.
> When I get errors from this tool, I always suspect it's misinterpreting
> something somewhere, and in a matter of days I just switch back to a more
> traceable system, rather than having to check by going through all the
> subsets of special words possibly involved..

We can, of course, disable "implicit" features, like <toolset>, so that you 
need to always use the syntax above. However, I somehow sure that we'll get 
complaints for user if insteead of

bjam gcc-3.2

it will become required to write

bjam toolset=gcc tooolset-gcc:version=3.2

> for instance, if someone works on evolution and names a target darwin, how
> will it behave with the current syntax ??

E.g. if you have both target 'darwin' and toolset 'darwin'. Then, I think 
plain 'darwin' on command like will be taken as toolset name. To use target 
you'd have to use

bjam .//darwin

-- ".//darwin" can be only target reference.

> >> Having a little redundancy in the syntax is good as it allows more
> >> helpful error messages. ATM an error in a jamfile/project-root.jam
> >> typically shows up at the very end of processing, nested insid a dozen
> >> line reports of internal jam file of the Boost.Build system.
> >
> > That's a problem, true.
> > I though that we probably should print more user-friendly context on
> > errors. E.g. when building target 'a', a message "Building 'a'" would be
> > added to context and printed on error.
>
> yes that would be useful, but most of all would it be possible to try and
> have the first line of the error report *always* point to the adequate user
> file and line ?

This should be doable, but it can't be automated. IOW, for all calls to 
errors.error it should be necessary to check if it's user error or internal 
error, and if it's user error to change diagnostics property.

> The fact error reports can nest a dozen internal files before concluding
> with :
> /home/sam/progs/boost-build.jam:1: in module scope
> is IMO a strong issue.
> (that's e.g. the case if you missed the definition of SOME_PATH and have
> somewhere in the middle of boost-build.jam :
> include $(SOME_PATH)/stuff.jam ; )
>
> this case demosntrate the 2 issues I find in boost.build parsing error
> reporting :
> 1. the origin of the error is reported with very approximative precision
> 2. the line concerning user file is not shown first. (I like hitting my
> 'next-error' key to point me to the origin of the problem, in my own files,
> not some terminal effect of the original input error. compilers do
> consistently report the erroneous user file first)
>
> I know that 'user-files' are not clearly dissociated from 'internal' files
> of Boost.Build, they're all jam files treated equally by bjam, but there's
> probably something to be done even though.

We can skip all files which are in BOOST_BUILD_PATH from backtrace, assuming 
they are internal files.

Maybe, you could file enhancements request in our tracker in

http://zigzag.cs.msu.su:7814

So that this is not forgotten amoung all the other things?

Thanks,
Volodya