Re: [jamboost] Error messages need help

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-17 15:28:58

Beman Dawes <bdawes_at_[hidden]> writes:

> At 09:45 AM 10/17/2002, David Abrahams wrote:
> 
> >> "don't know how to make
> >> <status>libs/function/test\deprecated_syntax_test.cpp"
> >
> >Hum. I don't think this one is so bad. In any case, this one is in
> >fact coming from Jam's backend, and I'm not sure how easy it is to
> >make it better. Source targets that Jam looks for get searched in a
> >sequence of directories known as SEARCH. You can't specify an actual
> >absolute file path because there isn't one. The file wasn't found in
> >some sequence of possible directories. Well, I guess we could GLOB for
> >user-specified source in the front-end proccessing. That might slow
> >things down a little.
> 
> Well, even if "don't know how to make" was changed to "file not found", it 
> would be an improvement.
> 
> >All in all, I recognize this particular problem but consider it to be
> >low-priority.
> 
> Once you've learned that "don't know how to make" really means "file not 
> found", its low priority. But until you've learned that, it is a 
> showstopper.

It's a typical kind of message from any make system, which establishes
a dependency graph among files. If it doesn't have a file which is a
dependency of some target being built, and it doesn't have
instructions to make it, it says "I don't know how to make
that". That's why I consider it low priority. This one doesn't confuse
too many people.

> >> "don't know how to make <borland><*><cxxflags>-w-8026 -w-8027 -w-8057
> >> -w-8084 -w-8092"
> >>
> >> That one is so obscure to me as a non-expert user that I have no idea 
> what
> >
> >> is wrong, so can't suggest better wording. The same attempt to 
> suppress
> >> borland warnings appears a number of times in the Jamfile, why one is
> >> somehow deficient is a mystery.
> >
> >I think when you were copying from this, you overlooked a colon:
> >
> > : [ run libs/utility/counting_iterator_test.cpp : # args
> >here----------------------------------------------------^^^^^^^^
> > : # input files
> > : # requirements
> >
> > # borland warns incorrectly in this case, so often that
> > # successful compilation is prevented.
> > <borland><*><cxxflags>"-w-8091 -w-8092"
> 
> So now we have to learn that "don't know how to make" might mean "file not 
> found" or it might mean "syntax error in Jamfile at some unknown 
> location". 

No, it doesn't mean there's a syntax error. Jam syntax is perhaps too
liberal, but it's definitely not a syntax error. It's a usage error.

> How many other things can it mean?

Try to put aside your outrage for a moment, and consider that if you
write a C++ function with this signature you have a similar issue:

void run(string test_file, string args = "", string input_file = "", string requirements = "");

If the user forgets about args and passes his requirements string
in the position of input_file, there's a similar problem.

> I wasn't the person who made the typo, so didn't have the advantage of 
> knowing that the above line had been changed. 

Which line changed?

> I was forced to guess that the problem was in the Jamfile, and
> search for lines containing "<borland>".
> 
> > Input file "<borland><*><cxxflags>-w-8091 -w-8092" not found
> >
> >Do you think that would be much better than what you're seeing?
> 
> No. It's apparently a syntax error. 

Nope.

> The usual practice is to say so, and give the file and line number
> of the point where the error was detected.

Well, maybe we could do something based on the fact that file names
are usually not allowed to contain '<' or '>' characters, but that
would only catch a subset of this kind of error... Hmm, right now all
requirements have grist, so maybe that would catch all cases of this
particular error.

> I personally don't see how anything less than that is acceptable, although 
> even just identifying the file and line number would be much better than 
> the current situation.

Well, it's nontrivial in v1. In v2 we have a nice backtrace framework
which can give you a call stack backtrace with file names and line
numbers. It would be a lot

> While better error messages might be lower priority than fixing the
> problem that causes regression testing to report success when in
> fact a library build failure occurred, I still think the error
> message problem is serious. It is a serious frustration and time
> waster, at least for me.

The problem is that it's hard to figure out what things to check
for. It's not as though the language itself gives us much to work with
in terms of syntax. Any rule invocation can take any number of
arguments, each of which is just a list of strings, and a missing
argument translates into an empty list. My argument list declaration
extension helps a lot, but when some arguments are declared with ?
(one optional element) or "*" (zero or more optional elements) it
becomes very difficult to handle the case where someone simply omits
an argument in the middle of the argument list. Everything shifts
over.

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html