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.