lua-users home
lua-l archive

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

I'd like to hear a distributions package manager opinion on this whole issue. I have the idea  that they love auto*, since it can do a lot of things out of the box they need we upstream devs never would think of for example configureable different installation paths for installation root, binaries, libraries, includes, docs). Having to add a patch to the upstream is the last resort and usually an unwelcome solution, since this patch has to be redone and rechecked with every release. Also for example debian with its ~35.000 packages, I suppose its not thrilling if each and every of these comes with its freaking own custom build system. As normal customer, I _do_ like packages (which are not among the 35000 in the distro) that come with a ./configure which tells me right away what I'm missing, autodetects what my sytems can and can't etc. 

On the upstreams side I agree. The auto* tools are hard to understand as non-expert on them and I had quite a fight with them, until it generally did what it should. I have for example yet to find a good MACRO to test for existence for liblua. Many other libs have ready made Macros in the auto*stuff, but not LUA. I looked around how others did it, and discovered those LUAers of us who use autotools are the vast minority. I ended up with this:

PKG_CHECK_MODULES([LUA], [lua5.1  >= 5.1.3],,[
PKG_CHECK_MODULES([LUA], [lua51   >= 5.1.3],,[
PKG_CHECK_MODULES([LUA], [lua-5.1 >= 5.1.3],,[
PKG_CHECK_MODULES([LUA], [lua >= 5.1.3])

But it sucks, since it checks for the package instead of the library. A proper Macro should have a little test.c that binds to liblua and have it test if it compiler, and if, have it output the liblua's version! Never had the drive to develop one myself.

I suppose a general simple makefile is an unoptimal solution, unless it really supports everything as Paramters what the package maintainers need. But I also think they are all far to humble to ever complain and understand their job as to cope with anything that comes from upstream, comfortable or not. Also flags that entail whole systems are to be avoided compared to flags for each and every capability, since albeit the tendency of monopolization in computer science there is still a vast amount of systems.

BTW. Maybe it just an urban myth, but i was told that the autotools originally was a result of research about "why computers suck" and it as a major relief. Supposedly in the 1980ies with a much higer diversity ecosystem on unixish systems it did. Its not without its own paradox nowadays its considered by many to be part of suckage.