openssl: add asm support for windows-x86_x64/windows-x86

[Teselka]

Adds support for the openssl's assembler files by using GNU/Netwide Assembler on Windows.
One bad thing is that it generates WARNING: Project targets '>= 0.55' but uses feature introduced in '0.64.0': Adding NASM language. when configuring the project.
Not sure what to do with this one, should i bump the minimum required version?

[eli-schwartz]

@nazar-pc

[benoit-pierre]

For the warning: you can update the initial project(…) call like this.

[bgilbert]

For the warning: you can update the initial project(…) call like this.

Isn't that structure redundant though? Meson won't warn about properly version-gated constructs even if the version in the project() call is lower.

[benoit-pierre]

This should probably keep warning(…) if ASM support is disabled on x86 / x86_64.

[Teselka]

Sure? Another arch/os combos doesn't have such warning

[benoit-pierre]

I don't know… There's no summary(…) call at the end, but there's a message, not a warning, in case of no-asm… ¯\(ツ)/¯

[eli-schwartz]

If someone disables a feature via an option we don't need to warn them:

• that the build system is incapable of offering that feature for their configuration
• that the build system is capable, but they have turned it off (they know they turned it off)

If something is optional and auto detected at configure time, then is the right time to warn people that functionality which they might have assumed would be built, is not being built.

[eli-schwartz]

A summary might be apropos. Those don't abort when using --fatal-meson-warnings.

[eli-schwartz]

Not sure what to do with this one, should i bump the minimum required version?

People on Windows who end up running the code in the if certainly need that new meson version, in which case bumping the minimum is apropos.

But Linux users don't need it. Is it worth bumping a minimum over this? I don't know.

If you do not bump the minimum then you'll need to guard that logic using if meson.version().version_compare('>=0.64.0') and gracefully degrade to not provide those features to windows users running old meson. No warning will be issued for code behind such a guard.

[benoit-pierre]

For the warning: you can update the initial project(…) call like this.

Isn't that structure redundant though? Meson won't warn about properly version-gated constructs even if the version in the project() call is lower.

That's not my understanding: if the project call ask for >= 0.55, but meson is 0.64 and a feature only supported on >= 0.64 is used, then there will be a warning, no?

[eli-schwartz]

For the warning: you can update the initial project(…) call like this.

That... Uh. Looks kind of dangerous 👀 because it erases warnings for code not in a version guard, on top of version guards will already suppress warnings when detected.

[benoit-pierre]

Well, it definitely does not work with curl in this case.

[Teselka]

Suppressed this warning properly i guess

wrapdb/subprojects/packagefiles/openssl/meson.build

Line 130 in c28e9f8

has_win_asm = add_languages(meson.version().version_compare('>=0.64') ? 'nasm' : '', native: false, required: false)

[eli-schwartz]

Please use if/endif conditionals, not ternary argument passing.

Well, it definitely does not work with curl in this case.

Meson's version guard handling is implemented by introducing a context inside the body of an if/endif. In your case, you are building dictionaries of kwargs but the actual call site that uses it isn't guarded by a conditional. It might still be possible to detect this by tagging the kwargs dictionary with an attribute somehow, but no one has designed an implementation of such a thing...

I understand why you did it the way you did (repeating the function twice isn't very DRY and this one is particularly bulky) and I cannot say I'd have done differently in your shoes, but nonetheless... mechanically, that's not what meson recognizes as a version guard. :(

[benoit-pierre]

Please use if/endif conditionals, not ternary argument passing.

Well, it definitely does not work with curl in this case.

Meson's version guard handling is implemented by introducing a context inside the body of an if/endif. In your case, you are building dictionaries of kwargs but the actual call site that uses it isn't guarded by a conditional. It might still be possible to detect this by tagging the kwargs dictionary with an attribute somehow, but no one has designed an implementation of such a thing...

I understand why you did it the way you did (repeating the function twice isn't very DRY and this one is particularly bulky) and I cannot say I'd have done differently in your shoes, but nonetheless... mechanically, that's not what meson recognizes as a version guard. :(

Makes sense, cleaned up in #1680.