If we are building with Lua support and it's not possible, the build should fail, not disable Lua

[victoryforce]

Instead of disabling the Lua support because a required library and permission to use the in-tree copy are missing, the build should fail. This behavior helps maintainers of distro packages. For them, automatically disabling functionality if the build environment doesn't meet the build requirements is the worst option, as they have to carefully study the build logs to avoid losing functionality. Failing the build in this case is much better.

Fixes #20680.

Replaces PR #20691 as it is very important to be able to build without Lua for debugging purposes.

[wpferguson]

as it is very important to be able to build without Lua for debugging purposes

Why do we need to debug without Lua? The windows hang is a case in point. Lua exposes the race condition at startup when changing views.

For 5.6 the scripts are going to be built in to the release. The scripts provide bug fixes for darktable issues. So, to me, it seems that Lua should be required, not optional.

If Lua is optional, then packagers can decide to just --disable-lua if they don't want to "deal" with the different Lua versions.

[victoryforce]

as it is very important to be able to build without Lua for debugging purposes

Why do we need to debug without Lua?

For the same reason we debug or ask users to test whether the problem is reproducible with OpenCL disabled - different/additional execution paths.

The scripts provide bug fixes for darktable issues. So, to me, it seems that Lua should be required, not optional.

I also believe that Lua should be integrated in official builds (whether ours or those in distributions). The problem is not that packagers refuse to make official packages with Lua support. I have not seen any such case. The problem is only that with our current build configuration logic, a regression is possible that will go unnoticed (due to auto-disabling Lua support instead of a failed build).

If Lua is optional, then packagers can decide to just --disable-lua if they don't want to "deal" with the different Lua versions.

I'll tell you one secret. I've been a package maintainer (several hundred packages, so it's no walk in the park) on two distributions for far more years than I've been a darktable contributor (started in the last millennium :) ). And trust me, I guarantee you that if a maintainer decides they know better how to build a package on their distribution, they'll patch it.

If a packager decides something, it'll be done regardless of whether it's just --disable-lua or whether it needs to be patched (there are plenty of such patches in the distro's package repos).

[wpferguson]

Now I know more about packaging 😄

[victoryforce]

Oh, there are many dark secrets there. 😄 For example, maintainers often (too often) make patches to fix real problems/bugs in upstream apps but are too lazy to push them upstream.

[TurboGit]

Thanks!