From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-10-17 15:27:59
At 09:45 AM 10/17/2002, David Abrahams wrote:
>> "don't know how to make
>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
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
>> "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
>> is wrong, so can't suggest better wording. The same attempt to
>> 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
> : # 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". How many other things can it mean?
I wasn't the person who made the typo, so didn't have the advantage of
knowing that the above line had been changed. I was forced to guess that
the problem was in the Jamfile, and search for lines containing
> 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. The usual practice is to say so, and
give the file and line number of the point where the error was detected.
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.
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.
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