lua-users home
lua-l archive

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

Ok, so I began to work on the Makefile part to isolate changes introduced in Lua-i18n. The idea is to have several Makefile variables, so that each i18n facility can be enabled or disabled at compile time. So if you disable all of them, you end up with the same result that you get with the official Lua.

Ideally, you should just have to let each internationalization cflags alone when you want the feature, and comment the others. Then make should compile everything seamlessly, the Makefile adding dependencies (or not) based on cflags (un)definition state.

The easy portable part is defining C macro variables in the Makefile to make changed code conditional. The more difficult part is making part of dependencies conditional in a portable fashion. Indeed most make implementation out there include some conditional control structure, but it's seems that currently there is no standard straight forward portable solution. At least, I didn't found one.

But maybe you have some thoughts to share on the matter. :)

Related reading:

http://gallium.inria.fr/blog/portable-conditionals-in-makefiles/

https://docs.google.com/document/d/1oUR7iMnaNzkeT3TTOS-Gwul6_V3TE8caIDAd1FwPyNc/edit#

https://www.gnu.org/software/make/manual/html_node/Conditional-Syntax.html

https://www.mkssoftware.com/docs/man5/makefile.5.asp


Le 22/11/2016 à 08:26, mathieu stumpf guntz a écrit :


Le 22/11/2016 à 06:25, Dirk Laurie a écrit :
But (finally returning to the topic of the thread) the fact that APL
and Lua for all practical purposes inhabit different lexical worlds
makes it possible to write a single interpreter that mixes APL and
Lua at use input level. I'd hate to give that up. Si I guess that I don't
want internationalization in standard Lua. Call it Lua-i18n as the
OP said, but please keep that i18n in the name at all levels. Don't
call it Lua.

For the part which enable to use other lexems than the default reserve ones, the idea is to make that only through a loadable scope contained feature.

For the internationalization of error messages, it should not introduce any change in the language interpretation. Possibly this might have an impact on the executable size, but it also might have some way to manage that as an optional feature at compile time so you get zero extra weight. Possibly you may even scrape some bytes with a "null" locale which get rid of messages or at least use void string. Feedback is welcome if you have some suggestions on this topic.

For the unicode support, I don't yet have enough knowledge to forecast what the consequence would be. But once again, this might be implemented as an optional feature at compile time. You might even think of more character encoding if you are nostalgic of the good old ISO 8859 mess or that you have some peace of software that you need, can't make evolve, and rely on non-ASCII character encoding.

Which point would still sound problematic to your mind? Can you please provide some details, possibly with an concrete code example of how it would be problematic to you?