I'd still argue that it's of lesser value to user. In the essence "NOTE" formulation implies "you expected to see something else, but you don't". But thing is that majority of users don't really expect anything. Because they don't run config multiple times a day like we are. They simply look at INSTALL and try to make sense of whatever that appears on the screen. For example, just before "NOTE" it prints "Creating Makefile". I'd say that what would make more sense to user is to write read "if make fails, include output from following command to problem report." In other words message should be used as communication channel to unsuspecting user.

Oh! On related note. There is a valuable piece of information that went lost in the recent changes, and it's user's perl version string.

Ah, good point re perl version string.

Regarding unsuspecting users, I certainly hope that they read README as well, which has a whole slew of stuff that we want them to tell us... I most certainly hope they do read that file...

Another valuable piece of information that is missing in --dump output is cross-compile prefix. Well one can spot it in command line or recorded environment, but thing is that they are far apart. Basically what I'm saying is that it might be appropriate to consider even how usable is it to us, the receiving part of problem report. I mean such verbose --dump output can answer a lot of questions, but it still might be appropriate to make it easier to seek answers to most common questions for less prepared member, one who doesn't know all the intimate details about build system. To give an example. Configure linux-mips32 --cross-compile-prefix=foo-bar-. What I'd like to see is which compiler command line that was used. As it is now I'll have to observe --cross-compile-prefix in config command line in the beginning of output and assume that it's gcc is prefixed with it. It has to be known by heart, and question is if it's reasonable assumption that everybody does?

What I meant to say is that I'd rather not reproduce that slew of stuff in a note at the end of configuration... perhaps better to simply refer to README?

Regarding this PR, one thing I could do is to have this message disappear for the 1.1.1 release, i.e. only be displayed now and through the pre-release period. From past experience, I think it's safe to assume that those running master now, or the pre-releases do configure again and again a bit more often than the unsuspecting user...

perhaps better to simply refer to README?

Yes, It's an option too. But then with explicit reference to SUPPORT section. However! There is ambiguity. The said section discusses rather case of failed 'make test'. Indeed, it says things like "remove optimization flags" (without telling how btw, which implies quite advanced user), and submit output from 'openssl version -a' (which kind of suggest that it's even 'make install'-ed?). While what we are talking about here is rather case of failing 'make'...

Good point

have this message disappear for the 1.1.1 release, i.e. only be displayed now and through the pre-release period.

I'd rather not do that. Thing is that those who run it often will quickly become blind to what it says anyway. There is really no reason to think about anything anybody else but unsuspecting user.

So basically, you'd rather rip this note out entirely. Yeahok, I can do that.

you'd rather rip this note out entirely

Well, it's kind of a trick question. Yes, I'd rather rip the note as it reads now, but at the same time I don't think there is no place for a message to unsuspecting user. And on some level I for one would even argue that original output was such message. Arguably subtle and implicit, but nevertheless. For reference one of ideas about it was specifically to attempt to concentrate on what is likely to be problematic. It was intended to be reflection of common configuration problems that we're running into, and as such was not meant to be carved in stone, but evolve over time, removing thing we feel confident about not causing problems, and adding new ones we learned to cause troubles.

See #5247

The trouble with your line of thinking is that we've ended up asking people to dump their whole Makefile or configdata.pm because the data from Configure wasn't sufficient. I would argue that it's better to have a bit too much information than a selection that we thought would be enough at one time... basically getting the full picture in readable enough form. But throwing all that in the face of the unsuspecting user isn't ok, so the logical outcome is to display the information on request.

I'm closing this in favor of #5247

The trouble with your line of thinking is that we've ended up asking people to dump their whole Makefile or configdata.pm because the data from Configure wasn't sufficient.

That's a strange conclusion. I've never said that original output was supposed to be all sufficient. The intention was not to arrange it so that one never has to ask for configdata.pm or Makefile. Intention was only to be able to address more or less obvious blunders [without having to ask for configdata.pm and Makefile]. To give an example, configuring for mips on x86_64 system without specifying cross-compile prefix... Another example would be attempt to use MSYS perl with VC-WIN...

throwing all that in the face of the unsuspecting user isn't ok, so the logical outcome is to display the information on request.

Never said it was ok either. As already said, there a place for a message. And one of questions is of course how long should it be. Note that previous output was a truncation of one from 1.1.0. Yes, one can argue that even that one was way too long [or too implicit], but it doesn't mean it's actually suggested to throw everything in face of unsuspecting user.

Yes, one can argue that even that one was way too long [or too implicit]

I do argue that, obviously

but it doesn't mean it's actually suggested to throw everything in face of unsuspecting user.

I haven't said that anyone has suggested that explicitely. However, having had to ask for more data than what Configure gave, or having had others misinterpret insufficient data (#5087) has made it apparent to me that we cannot guess what is actually useful, not only to us but also to our users, for example people who're trying to make their private config targets work. So the conclusion from these observations is that it's better to display a full picture to the best of our capacity and in a way that's kind(er) to the eye.

This being said, I think that if we shall continue to discuss, it'd be better to do so in #5247.