I for one would very much appreciate if CC value was expanded as it would be when make is executed. I mean if I pass --cross-compile-prefix=foo-bar-, I'd appreciate if configdata.pm printed CC = foo-bar-gcc. This applies to all tools. I'd also say that having makedepprog in dump can be useful...

I for one would very much appreciate if CC value was expanded as it would be when make is executed. I mean if I pass --cross-compile-prefix=foo-bar-, I'd appreciate if configdata.pm printed CC = foo-bar-gcc.

Sure. Does that mean that in unix-Makefile.tmpl, we should remove the CROSS_COMPILE variable and change this kind of construct:

CC= $(CROSS_COMPILE){- $config{cc} -}

to:

CC= {- "$config(cross_compile_prefix}$config{cc}" -}

?
That would be nice for consistency.

As for reference to #5087 in #5242. It's not exactly fair example. What I was referring to was specifically "blunder" cases, i.e. when configuration is known to normally work, but doesn't for somebody for presumably odd reason.

What I was referring to was specifically "blunder" cases

Yes, I get that, but what I trying to say is that this is not all that the variable output is used for!

Does that mean that in unix-Makefile.tmpl, we should remove the CROSS_COMPILE variable

Hmm, trick question. If given a choice between pretty print and keeping CROSS_COMPILE variable in Makefile, I for one would choose latter. Because I appreciate the possibility to say make CROSS_COMPILE=some-thing-else- to [temporarily] override it. On the other hand it's not really inappropriate to "freeze" things, so that make behaviour is more controlled even if you happen to run it in another window where you had some specific environment variables set. On 3rd hand practically everything can be overridden, so why CROSS_COMPILE should be frozen... So my choice would still be latter, i.e. keep $(CROSS_COMPILE) in Makefile...

@levitte you asked me to review, but I don't have anything that would be useful beyond the dialog you and @dot-asm are already having. So I won't review this :) and just watch the Swedes fight. (Ha, how often do you get to say that kind of thing?)

On 3rd hand practically everything can be overridden

By the way, this reminds me one thing. This is a side[!] note [in the context]. One can actually wonder if it's wise to allow CFLAGS or CPPFLAGS [or others] to be overridden the way they are now. It's easier to explain with CPPFLAGS. As you might notice its value affects outcome in significant manner, consider -DOPENSSL_BN_ASM_MONT for example. So that if user manages to override it (not quite unthinkable if OpenSSL is build as part of some other project), it would have quite a consequences [not only on performance, but potentially even security, think constant-time.] What I'm trying to say is that it might be appropriate/wise to arrange things in such manner that CPPFLAGS is something that is added to flags, as opposite to overriding whole set of them. For example rules can have $(CPPFLAGS) $(CPPFLAGS_CONFIGURED) with obligatory/non-overridable pre-processor flags assigned to CPP_CONFIGURED. [Similar would apply to $(CFLAGS) $(CFLAGS_CONFIGURED), maybe to some others.] [Another alternative to CONFIGURED suffix can be OBLIGATORY.]

[Just in case for reference. In 1.0.2 this is resolved by clearing CFLAGS before make is invoked in subdirectories. And by Makefiles in subdirectories having $CFLAGS=$(INCLUDES) $(CFLAG) assignment. Where $(CFLAG) [note no S], works as above suggested $(CFLAGS_CONFIGURED). It's defined in top Makefile.]

Re display make variables (pretty-print) vs what's in Makefile, I've realised that they don't have to be exactly the same, so I'm implementing pretty-pring of prefix+cmd where applicable.

With my last two comments in mind one can wonder if it makes sense to introduce a target to Makefile that would not only dump configdata.pm, but even display chosen make variables as they are evaluated in actual make attempt. [This incidentally answers question about message to unsuspecting user. I mean it could read "If make attempt fails add output from 'make <the-said-target>' to problem report." I'd probably argue that it should be decorated with star box(*).]

(*) Example of "star box":

**************************************************
***                                            ***
***   Please run the same make command again   ***
***                                            ***
**************************************************

Regarding your side note, I've had some thoughts on that... and it kind of goes with the fact that we apply configured defines everywhere when they really only apply to the libraries. SO, there are already make variables starting with LIB_, DSO_ and BIN_, and I was thinking that those could be put to better use.

Added support of pretty-print of cross compile prefix in configdata.pm, and remove the --host commit.

For the side note stuff, I'm going to do that work in a separate PR.

wonder if it makes sense to introduce a target to Makefile that would not only dump configdata.pm, but even display chosen make variables as they are evaluated in actual make attempt.

Just in case it wasn't obvious. If you get make to print actual evaluated variables, then I wouldn't care if toolchain components in configdata.pm -dump were prefixed with cross compile. Moreover, I think it would be more than appropriate to have make print evaluated variables. I'd even simply ask here in this PR or elsewhere?

Since it's kind of usability thing I have couple of remarks.

Currently output reads

Using implicit seed configuration
Configuring OpenSSL version 1.1.1-dev (0x10101000L) for linux-x86_64
Creating configdata.pm
Creating Makefile

I'd say that "Configuring" line should be first, and that "seed configuration" should read "random seed configuration". I mean it's not clear what kind of seed is it, and it's not clear what is it talking about. In sense that if "Configuring" is second line, then one can as well read the first line as "it's some perl thing."

Secondly, touch Configure and run make. If output from Configure is reduced to just handful of lines, then I'd say that output from automatic reconfigure should also be reduced to couple of additional lines.

I've added commits to fix the output of seed info, and to make make reconfigure less verbose.

I think that a target that displays all applicable make variables is a good idea. It may take a few hours before it shows, as I'm currenty traveling on boat and have no idea for how much longer I have connectivity with the coast...

I think that a target that displays all applicable make variables is a good idea.

Sounds like you want to do in this PR. All right...

BTW, red cross from Travis is unrelated.

Sounds like you want to do in this PR. All right...

No, I'll make it in another PR. The difficulty comes if there's a metacharacter somewhere in a value (which might very well be the case for CPPFLAGS or CPPDEFINES). That's going to screw up the display.
So, please judge this PR in its current form. I suggest making an issue for a Configure wish-list.

judge this PR in its current form

Well, one of reasons why this PR came to be was message to unsuspecting user. And there is no one. So it went out of scope?

With cross-reference to #5248 I'd like to clarify that even if we choose to restore [part of] visual feedback about configuration parameters, it doesn't mean that message to unsuspecting user would become irrelevant. It would still make sense to add make target, buildinfo perhaps, and leave suggestion to execute make buildinfo in case make fails.

Well, one of reasons why this PR came to be was message to unsuspecting user. And there is no one. So it went out of scope?

Not exactly. I removed the current message because it wasn't good enough (I agree!), but I would like to see a better replacement (just not a dump like we had before), and am asking for help formulating thst better message. I do hear that a message geared toward problem reports (in my mind, that means mentioning perl configdata.pm --dump) would be a good thing...

Ultimately what we want out is whatever you need to do in order to reproduce the build context.
So if you have stuff in environment vars that effect the Configure output andhte Configure command line then I think we actually get what we need - i.e. how to reproduce the users build choices.

I made a change that has Configure emit this message at the end:

: ; make reconf
/usr/bin/perl configdata.pm -r
Configuring OpenSSL version 1.1.1-dev (0x10101000L) for mingw
Using implicit random seed configuration
Creating configdata.pm
Creating Makefile

**********************************************************************
***                                                                ***
*** If you want to report an issue with building, please include   ***
*** the output from this command:                                  ***
***                                                                ***
***     perl configdata.pm --dump                                  ***
***                                                                ***
**********************************************************************

Ping!

Ok. Merged. d5fa703 to a1b6933