[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: build optimizations
- From: Natanael Copa <natanael.copa@...>
- Date: Thu, 24 Mar 2011 10:34:52 +0100
On Tue, Mar 22, 2011 at 1:24 PM, Luiz Henrique de Figueiredo
> 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
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
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