Re: Matching multibyte alphabetical characters with LPeG

[Jay Carlson <nop@...>]

On Jun 20, 2012, at 8:48 AM, Roberto Ierusalimschy wrote:

>> Also, why is l_newpf exposed through the registry?
>> `lua_pushcfunction(L, (lua_CFunction)&l_newpf);  /* new-pattern function */`
>> I found this really odd: why not expose it directly (so I can link
>> against lpeg);
> 
> This may change; the idea was exactly to avoid fixed links. Independent
> libraries could be independently compiled.


Consider Debian's rules for libfoo-dev packages. lpeg.h comes with liblpeg.so, and lpeg.h describes that version of the API. Code which includes *that* lpeg.h (whether a main program, another library, or a plugin) should then link with *that* -llpeg. The versioned name (such as liblpeg.so.1) linked against is recorded. By having client code link against API dependencies, there's no possibility of undiagnosable version skew between headers and library. New releases use the same versioned name as long as they have an identical API.

The dynamic linker would like to be your friend. It has grown up a lot....

There's still one problem, which should happen less often: multiple libraries calling for different versions simultaneously, like liblpeg.so.1 and liblpeg.so.2. Given the default flat global C namespace, somebody has to lose. Modern Unix systems have various complicated ways of dealing with this available.

Jay