lua-users home
lua-l archive

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

On Tue, Mar 22, 2011 at 01:31:44PM +0100, Henning Diedrich wrote:
> On 3/22/11 1:24 PM, Luiz Henrique de Figueiredo wrote:
> >Here are two points on the build process that we'd like your input on:
> >
> >1. The Makefile assumes gcc. So we might as well use all gcc-specific flags
> >    to get a better Lua core and interpreter, for some definition of "better".
> >    For instance, -fomit-frame-pointer seems to generate smaller and faster
> >    binaries, but a Lua library compiled with -fomit-frame-pointer might not
> >    be debuggable. Is this really a bad thing? Or will anyone needing to debug
> >    the Lua library add the source code to the project and thus not rely on
> >    whatever pre-built Lua exists in their system?
> Totally, plus it's fading away with x64.

Not everybody in the world is using x86 or AMD64.  It's still import for
other platforms where Lua is used (ARM, for example.)  This flag has a
pungent scent of micro-optimisation.

To be honest, I'd rather it just use cc or $(CC) and friends, and not
hard-code GCC.  This has all sorts of advantages, and developers and
packagers can still tweak optimisation flags themselves.

> >  What gcc-specific flags
> >    should we use if we go that way?
> i686, wouldn't anybody working with something smaller be a pro who
> knows what he is doing and have no problem fixing the flags?

I'd certainly object to this in the Makefile!  It'd mean it was
compulsory to edit it to build it on non-x86.

> >2. The file all.c (aka one.c) allows Lua to be built as a single object file,
> >    and allows the compiler to generate better code and with just the Lua API
> >    as public symbols. We are considering building Lua in this way, so that
> >    liblua.a will consist of a single object file. Does anyone see a drawback
> >    to this?
> Not at all, compile times can't be killing anymore for this

If mandating GCC, GCC has a flag for this.  Although I admit I have no
idea how well it works.  (Certainly, all sources must be passed
simultaneously; I do not know if it just internally concatenates them or
if it does something more involved to make sure statics don't clash.)