feat: add Lua 5.5 support when available

[airween]

what

Add Lua 5.5 version to build/find_lua.m4 script.

why

This helps to recognize Lua 5.5 if it's available.

The code didn't need to align as in #3525 for v3.

Note, that I installed Lua5.5, built the source with it and run all regression tests - everything was perfect. GH workflow for Windows also uses Lua 5.5.

notes

I changed the order of the versions because the script recognized the installed Lua versions from the lower version to the highest ones. Now the highest version will be used.

[Copilot]

Pull request overview

Updates the Autoconf Lua detection macro to recognize Lua 5.5 via pkg-config and to prefer the highest installed Lua version when multiple versions are present.

Changes:

• Add Lua 5.5 pkg-config module name variants to the detection list.
• Reorder the Lua pkg-config module names so newer versions are selected first.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

build/find_lua.m4:113

• lua_lib_path / lua_lib_name are not initialized before the fallback search. Previously they were actively cleared on each failed probe; with the refactor they’re only set on success. If either variable is set in the environment (or left over from earlier configure logic), the test -n "$lua_lib_path" check can short-circuit the search and yield a false positive. Explicitly initialize/clear these variables (e.g., before entering the loops or at the start of each x iteration).

    for x in ${test_paths}; do
        for v in 5.5 5.4 5.3 5.2 5.1 51 ""; do
            # Generate the necessary names: lua5.5, lua5.4 ... lua51 (legacy) or just simply lua
            curr_lib="lua${v}"
            if test -z "${v}"; then curr_lib="lua"; fi

            for y in ${LUA_SONAMES}; do
                if test -e "${x}/lib${curr_lib}.${y}"; then
                    lua_lib_path="${x}"
                    lua_lib_name="${curr_lib}"
                    break 2 # exit from two inner loops
                elif test -e "${x}/lib/lib${curr_lib}.${y}"; then
                    lua_lib_path="${x}/lib"
                    lua_lib_name="${curr_lib}"
                    break 2
                elif test -e "${x}/lib64/lib${curr_lib}.${y}"; then
                    lua_lib_path="${x}/lib64"
                    lua_lib_name="${curr_lib}"
                    break 2
                elif test -e "${x}/lib32/lib${curr_lib}.${y}"; then
                    lua_lib_path="${x}/lib32"
                    lua_lib_name="${curr_lib}"
                    break 2
                fi
            done
        done
        if test -n "$lua_lib_path"; then
            break
        fi

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.