[cmake-developers] FindLua.cmake module does not find a locally built lua library

[Alan W. Irwin]

This issue is due to the following NAMES logic (that is in all
versions from CMake 3.7.2 to the latest git version) of the
find_library command within FindLua.cmake.

find_library(LUA_LIBRARY
   NAMES ${_lua_library_names} lua
   HINTS
     ENV LUA_DIR
   PATH_SUFFIXES lib
)

_lua_library_names contains a bunch of different versioned names such
as lua5.3.  As a result the system version of the lua libraries (which
for Debian Buster lua5.3.3 contains a nasty bug that is fixed in
upstream lua5.3.5 which I have built locally) is always found no
matter how I set CMAKE_PREFIX_PATH (or LUA_DIR) because the local
build installs the lua library with the generic name liblua.a.  I can
work around that by installing an extra symlink liblua5.3.a ->
liblua.a in my locally built version of lua-5.3.5, but that
workaround should not be necessary.

There are at least two possible fixes for this issue in FindLua.cmake.

1. Use

    NAMES lua ${_lua_library_names}

    which follows the advice at <https://cmake.org/cmake/help/latest/command/find_library.html>
    to place the generic name first for exactly this reason (finding a local version).

2. Use the NAMES_PER_DIR option in the find_library command.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________