Re: autoconf / automake

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

Your summary seems fair enough, but I don't maintain packages.

Package maintainers live in a different world than I do, and it seems
to be the same world that contains autotools.

I do see that CMake has or can have a thing called CPack, which is
supposed to enable automatic generation of various kinds of packages.
I don't know how well it works.

I also know that some people are using SCons to automate package building.

The problem, as I do recognize, is that the people who e.g. maintain
Debian, or who maintain packages for different operating systems, feel
that they must take a "lowest common denominator" approach to their
toolkit. This is the philosophy underlying autotools themselves.

The resulting complexity is a wonder to behold.

In one of the systems I help maintain, a rather large and complex
project called Csound which runs on Windows, OS X, and Linux, and
which contains many options and languages, the maintainer of the
Debian package (who is not me) must produce a special build with his
own extra steps. I think he even has to patch the Csound source code.
I don't know if he uses any autotools stuff. (The Csound build system
itself uses SCons with a single SConstruct file and a customizable
file with lib/include paths etc.)

If I were the package maintainer, I would try to bring it all into
SCons, starting with the approach of
http://www.qandr.org/quentin/writings/debscons.

Regards,
Mike





On Thu, Oct 27, 2011 at 1:15 PM, Axel Kittenberger <axkibe@gmail.com> wrote:
> 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.



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