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

[Alan W. Irwin]

On 2018-09-24 11:07-0400 Brad King wrote:

> On 09/22/2018 07:09 PM, Alan W. Irwin wrote:
>> 2. Use the NAMES_PER_DIR option in the find_library command.
>
> This is the correct fix.
>
> The versioned names need to go first to try to match the headers.

I agree.  I have additional code in PLplot to find the Lua executable,
and the versioned name (e.g., lua3.2 or Lua3.3 on Debian Buster) needs to go first to be
consistent with with whatever header and library are found.  So I
solved the issue of finding the local build of lua in that case using
the NAMES_PER_DIR option on find_program.

Here is my code for doing this.

   string(SUBSTRING ${LUA_VERSION_STRING} 0 3 SHORT_LUA_VERSION_STRING)
   # Look for consistently versioned LUA_EXECUTABLE and only use the
   # "lua" name for that executable as a last resort because the
   # generic system version may not correspond to the library that is
   # found. But in order to find a locally built version (if higher
   # than the system version on the search PATHs) must also use
   # NAMES_PER_DIR.

   find_program(LUA_EXECUTABLE NAMES lua${SHORT_LUA_VERSION_STRING} lua NAMES_PER_DIR)

The current FindLua.cmake does not determine the location for a
a consistent lua executable so I suggest similar code to the
above is adopted in that module to add that functionality.

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
__________________________