On Tue, Mar 7, 2017 at 1:37 PM, Jacob Champion <champio...@gmail.com> wrote:
> On 03/07/2017 07:49 AM, William A Rowe Jr wrote:
>>
>> Ok, adding /usr/lib is a bad thing any and every day (and in this case,
>> completely bogus since it lives in /usr/lib64).
>
>
> Same on Ubuntu, where the actual libraries live in an architecture-specific
> folder under /usr/lib.
>
>> But I'm still not seeing how we pick one of several lua-x.x libraries
>> where
>> they all live in parallel... and not seeing why we would select lua-5.3
>> over
>> a defacto lua.h (which might be 5.4, 5.5 or whatever in the future.)
>>
>> Switching to a pkgconfig identifier as the first-guess of what PATH means
>> to --with-lua might be useful here, resolve any -lm -ldl and similar
>> depends
>> and avoid silliness like -L/usr/lib. Thoughts?
>
> Or just assume that if the --with-lua argument doesn't have a forward slash,
> it's meant for pkg-config.
>
> Seems reasonable to me, in any case. Do we have precedent for that somewhere
> else in the configuration?
I recently refactored (and significantly condensed) the pcre[2] detection,
but that isn't so much help because it is pcre[2]-config script-based query,
as opposed to pkgconfig.
Not that I have a comment on their style, but nghttp2 and openssl are
two examples.
We may want to have a --with-lua-ver= option (with 'no' mapping to
a non-revisioned install of lua), and yes (default) translating to the
testing suffix list "{empty}:-5.3:5.3:53:-5.2:5.2:52:-5.1:5.1:51" (although
I wonder if any architectures/distributions actually need anything more
sophisticated than "{empty}:-5.3:-5.2:-5.1"). This way the --with-lua=[PATH]
doesn't change meaning.
