lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Fri, Dec 04, 2009 at 10:27:29AM -0200, Luiz Henrique de Figueiredo wrote:
> > I think it'll probably remain an external addon; it's just a one-line change
> > in llex.c.
> 
> I meant, it's a one line-change to include a .c file that does whatever
> filtering you need. The point being that you can maintain your variants
> without messing with the Lua sources. 

Please, reconsider this approach. Matthew is right in highlighting the
fact that having to modify the source of a software to activate a
feature is not an option for software distributions.

Luckily out there there are not trivial projects based on Lua that would
benefit from token filters, but the fact that it is not a "standard"
feature refrains them for using it, since the would not run on a vanilla
Lua interpreter nor on a vanilla jitter. This is really a portability
issue.

Moreover, even if you really embed Lua is a software that is part of a
software distribution, you really want to use the system wide installed
shared object. You will get the minor versions updates for free (OK,
historically Lua has few bugs... but I cannot predict the future ;-) 
and you may also discover that your users have an easy option to use
Luajit without recompiling you software (if they are on a platform
supported by the jitter).  

Actually, my reasoning applies to all luaconf.h, but luckily here there
is a default; I hope all Linux distributions leave the file untouched.

Just my 2 cents wearing the Debian hat and hoping Lua steps out of the
"it's just for embedding" world. Cheers
-- 
Enrico Tassi