Re: build optimizations

[Natanael Copa <natanael.copa@...>]

On Tue, Mar 22, 2011 at 1:24 PM, 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.

As the distro maintainer for Alpine Linux, I'd like to say: make them
easily overrideable.

CC ?= gcc
CFLAGS ?= <whatever you prefer to be the "defaults">

I have the impression that packagers will use their own CC and CFLAGS
anyways. If you hardcode it, it will be patched out.

For example, personally I use CC="ccache gcc" and it could as well
have been CC="distcc gcc".

Same with CFLAGS. The packagers will override it with their
prefference (-Os if you think small size is more important than speed
for example)

While here, It would be great if the official makefile had support for
building dynamic liblua (yeah, i know that static is faster etc etc,
but sometimes you are willing to trade speed for other things like
size)

-- 
Natanael Copa