Re: PATCH: Lua5.1-work3 loadlib cleanups

[Mike Pall <mikelu-0412@...>]

Hi,

Adrián Pérez wrote:
> I tend to write the test for MacOS X like:
> 
> #if defined(__APPLE__) && defined(__ppc__)
>   /* MacOS X code goes here */
> #endif
> 
> I think the test is strong enough, I have never experimented problems 
> with it.

Well, but there is a Darwin port to x86. So when dynamic library support
is concerned the proper way is to test for __APPLE__ and __MACH__.
Incidentially that is exactly what Lua 5.1-work3 does. My patch just
rearranges the autodetection and wraps a #ifndef NO_LOADLIB around it.

I'm in the process of modifying Lua 5.1-work3 loadlib.c for Mac OS X
bundles. An updated patch will follow soon.

> >Still, I'd place shared objects under /usr/local/share/.           
>
> I don't think so. As far as I know, "/usr/share" (or
> "/usr/local/share") is intended for data used by programs, not for the
> code of the programs. Executable code goes under "*/bin" for programs
> and "*/lib" for libraries, so using a particular subdir under "*/lib"
> seems appropiate. That's the way the vast majority of software is

My patch sets the standard installation paths to:

Windows  Lua modules  C:\Program Files\Lua51\lib\?.dll
Windows  C   modules  C:\Program Files\Lua51\lua\?.lua

POSIX    Lua modules  /usr/local/share/lua/5.1/?.lua
POSIX    C   modules  /usr/local/lib/lua/5.1/?.so

(Mac OS X is the same as POSIX as far as naming is concerned)

I think this is compliant with standard dynamic library and data file
placement. Anyone who begs to differ, please speak up.

I'm aware of the fact that the 'Program Files' path on Windows is NLS
dependent. But there is nothing we can do about it without using special
APIs at runtime. Quite a few non-NLSized apps use the English variant and
work just fine (MS created that mess, I don't feel guilty :-) ).

Bye,
     Mike