I wonder if these warnings (introduced in commit 75c0873c), generated by "configure" on a system that doesn't have a uchardet library, overstate the case a little:
configure:20532: WARNING: uchardet library not found, preconv might not work properly configure:26790: WARNING: uchardet library was not found; preprocessor 'preconv', which uses it to detect the input file encoding, might not work properly (to check how and in which order 'preconv' tries to determine the file encoding, see its man page). In particular, the vagueness of the phrase "might not work properly" can imply the problem is more serious than it is. If the warning explained exactly what might not work, users could determine for themselves how serious it is (which, in most cases, is not very: this library's absence only eliminates one method (out of six documented) of determining the input's encoding -- and the method in question is an educated guess, so it "might not work" even with the uchardet library). I'd fix the first warning by removing the "preconv might not work properly" part altogether. This one is generated at the time the library's absence is discovered; the consequences of this absence should be saved for the later, more visible, more verbose warning. (As trivial side effects, this also eliminates the comma splice and keeps the message under 80 columns.) The second could be recast to say: uchardet library was not found; preprocessor 'preconv' will skip this method of attempting to determine the input encoding. (To check how and in what order 'preconv' tries to determine the encoding, see its man page.) In addition to being more precise about the effect, I've also edited "input file encoding" down to simply "input encoding" (since preconv's input needn't be from a file) and shortened the lines to be under 80 columns. Further refinements welcome.