Project

General

Profile

Support #976

configure: auxiliary scripts should be consistent about error messages

Added by John Abbott over 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Improving
Target version:
Start date:
18 Nov 2016
Due date:
% Done:

100%

Estimated time:
2.90 h
Spent time:

Description

There are numerous auxiliary shell scripts (in directory configuration/).
They do not have a uniform way of communicating errors: some print a message on /dev/stderr while others print a message on /dev/stdout (perhaps to be printed later by configure itself).

Review the situation, and try to be more uniform.

Perhaps also find a nicer format for the error messages; currently they are like this:

ERROR: configuration/verify-compiler.sh: Are you sure CXX is a C++ compiler?


Related issues

Related to CoCoALib - Bug #593: Temporary directories used during configurationClosed2014-07-20

History

#1 Updated by John Abbott over 7 years ago

  • Related to Bug #593: Temporary directories used during configuration added

#2 Updated by John Abbott over 7 years ago

  • Category set to Improving
  • Priority changed from Normal to Low
  • Target version set to CoCoALib-1.0

While unformity is nice, it is not so important if the existing scripts work well enough ==> low priority.

I think the error messages should contain the word ERROR, and they should also say which script printed the error; but from a normal user's point of view the main message (explaining what the problem is) should be given prominence -- at the moment it is too "mixed up with" the script name. Any ideas for how to improve this?

#3 Updated by John Abbott over 7 years ago

One suggestion for the format of the error messages is to use 2 lines, perhaps like this:

ERROR: Are you sure CXX is a C++ compiler?
ERROR: reported by "configuration/verify-compiler.sh" 

There is no problem with multi-line error messages which are printed directly; but if the message is stored in a shell variable then newlines are converted into spaces (so the message will appear on just one line). This suggests that it would be better to print error messages directly, rather than pass them to configure first... not sure if this is possible in all cases.

#4 Updated by John Abbott over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

Another possibile one-line format could put the script name in brackets somehow:
(first line is the current format)

ERROR: configuration/verify-compiler.sh:  Are you sure CXX is a C++ compiler?
ERROR: verify-compiler.sh:  Are you sure CXX is a C++ compiler?
ERROR[configuration/verify-compiler.sh]  Are you sure CXX is a C++ compiler?
ERROR(configuration/verify-compiler.sh)  Are you sure CXX is a C++ compiler?
ERROR[verify-compiler.sh] Are you sure CXX is a C++ compiler?
ERROR[[verify-compiler.sh]] Are you sure CXX is a C++ compiler?
ERROR: Are you sure CXX is a C++ compiler?  [from verify-compiler.sh]
ERROR: ***Are you sure CXX is a C++ compiler?***  [from verify-compiler.sh]
ERROR>>> Are you sure CXX is a C++ compiler? <<<ERROR  [from verify-compiler.sh]

It does seem less cluttered if the script name is just the last part (i.e. basename). This would be easy to change.

Comments? Ideas? Preferences?

#5 Updated by John Abbott over 7 years ago

Another idea is to have a configuration flag for "developers" so that the errors from scripts say which script gave the error; and the default is that the script does not identify itself. Or is this straying too far from KISS?

#6 Updated by Anna Maria Bigatti over 7 years ago

John Abbott wrote:

Another idea is to have a configuration flag for "developers" so that the errors from scripts say which script gave the error; and the default is that the script does not identify itself. Or is this straying too far from KISS?

I think it would be useful to know which script gives the error.
(I imagine we are called if something goes wrong in configuration ;-)

#7 Updated by Anna Maria Bigatti over 7 years ago

My preferred is

ERROR: Are you sure CXX is a C++ compiler?  [from verify-compiler.sh]

or
ERROR: Are you sure CXX is a C++ compiler?  [by verify-compiler.sh]

#8 Updated by John Abbott over 7 years ago

  • Assignee set to John Abbott
  • % Done changed from 10 to 20

OK, we can try with the script (base)name at the end of the message. It shouldn't take too long to make the change.

I might try double square brackets:

ERROR: Are you sure CXX is a C++ compiler?   [[verify-compiler.sh]]

#9 Updated by John Abbott over 7 years ago

  • % Done changed from 20 to 50

I have changed the format of the error messages in the existing shell scripts: the script name is now placed last (and between double square brackets).

There is still the question of whether to print errors on /dev/stdout or /dev/stderr (sometimes I am inconsistent even in the same file!)

#10 Updated by John Abbott about 7 years ago

  • % Done changed from 50 to 60

I am happy with the format of the printed error messages. It remains to decide between /dev/stderr and /dev/stdout.

#11 Updated by John Abbott over 6 years ago

I now think that it is best that error messages be sent to /dev/stderr since that is probably what most (experienced) users would expect.

I also like the simpler idea that the auxiliary scripts print out the error messages, and configure prints nothing (or perhaps just some supplementary information).

I'm making these changes now...

#12 Updated by John Abbott over 4 years ago

  • Priority changed from Low to High
  • Target version changed from CoCoALib-1.0 to CoCoALib-0.99700

Let's finish this soon! Boosted priority, and brought target version forward.
I think it is almost done anyway... but I must check.

#13 Updated by John Abbott over 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 60 to 100
  • Estimated time set to 2.90 h

A quick search with fgrep shows that all error mesgs are printed out on /dev/stderr
No doubt another check will have to be made later if any of the scripts are changed...
Closing.

Also available in: Atom PDF