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

From: Samuel Krempp (krempp_at_[hidden])
Date: 2004-02-04 07:25:39

le Wednesday 04 February 2004 08:16, ghost_at_[hidden] écrivit :
>> > The "-sTOOLS" syntax is gone in V2.
>>
>> Why is this so ?
> 
> 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.

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

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

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

-- 
Samuel