Re: build optimizations

[Michael Gogins <michael.gogins@...>]

One .c file is good, I like it.

In C++, you can have one header file with factory functions that
instantiate data objects as static variables in function scope. Don't
know if this would be possible for Lua but if so, you could do Lua as
just one single header file for use in other programs, no link options
required.

Regards,
Mike

On Tue, Mar 22, 2011 at 8:24 AM, Luiz Henrique de Figueiredo
<lhf@tecgraf.puc-rio.br> 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? What gcc-specific flags
>   should we use if we go that way?
>
> 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?
>
> All comments are welcome. Thanks.
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com