Re: build optimizations

[Axel Kittenberger <axkibe@...>]

> I'd suggest either continuing with a build target per platform, where
> there is a vanilla
> target that does not assume gnu chain (just cc, ld, ar), or else bit
> the bullet and put
> a real build system in.
>
> I dislike autotools as much as anybody, but it works, makes it easy
> for packagers, and there are enough people on lua-l familiar with
> autotools and/or cmake
> to maintain a working build.
>
> It might even be worth doing something sqlite-like: one release with
> split source and minimal
> gcc only Makefile, and the community does a follow-on parallel release
> with amalgamated
> source, and a build system friendly to packagers.
>
> I appreciate that the lua build system as-is allows a great deal of
> flexibility to packagers... but it
> is often unwanted and unused, and packagers might nott know enough
> about lua to choose
> correct build flags.

I second that. I too fought with autotools getting it to do the stuff
I want it to do. But I also get the feeling that package maintainers
appreciate autoconf, as its one big standard way for a ton of
packages. And it keeps many details highly configurable. Also users
seem to appreciate it, 'cause as *nix admin you soon learn about
./configure.

* The only exception are complaints, since I configured autoconf to
look for liblua as package, instead to test for it by trying to link.
For other standard libraries autotools give predeclared macros for
this, like libxml2 which I used before. If anybody has a suitable
autoconf configuration, that tests for the existence and version of
liblua instead of probing for the package information, I'd like to
have it.