Re: autotools alternatives, is anybody using autosetup?

[Sam Roberts <vieuxtech@...>]

On Tue, Jul 17, 2012 at 1:15 PM, William Ahern
<william@25thandclement.com> wrote:
> That's not too bad. Obvious issues are that one shouldn't put an explicit
> "/" after $(DESTDIR), and install is not a POSIX utility. It requires GNU
> Make, but that's fair.
>
>> It only supports two platforms, but not well, and I have to copy the
>> boilerplate approach to all my projects, where they slowly
>> desynchronize.
>
> You also have to write different code for each project. I don't see what the
> issue is.

The problems you point out above are a shining example of what the
issue is: and when I fix it, I have to hunt down all my projects and
fix it everywhere.

And actually, code reuse is a problem, too, I have a set of utilty
functions I cut-n-paste between projects, but that's outside of the
scope of the build tool.

> The search for the perfect automated build system is a fool's errand, IMHO.

I'm not looking for perfect, I'm looking for better, and to spend more
time writing src code, and less writing make/shell/awk.

>> Yes, I would. I just looked, and luajit appears to have only trivial
>> dependencies: a C library and gcc. Most of its 600+ lines of src/Makefile
>> is devoted to figuring out how to call gcc for the platforms it supports.
>
> And how many lines of autoconf'd M4 and shell code would be required to
> introspect this, or to declare it as an option through the build?

If you think I'm criticizing Mike's approach or think he should be
using autotools, you misunderstand me: I think what Mike is doing is
fine, and I think it's trivial.

> I've written and maintained an asynchrounous sockets and stub/recursive DNS
> library for several years.

Yes, I've been looking at it (and udns and unbound) recently.

It consists of a single .c source file, and has no dependencies, or
even an install target!

It works fine, but as an example of why everybody should do it that
way, its not so convincing.

And I see you copy your hairy EXE_CC macro into two makefiles in the
same project.

> Supporting all of those platforms (including kqueue/epoll/completion ports)
> in portable source code requires no support from the build system
^^^^^^^^^^^^^^^^^^^^^^^^

Portable close-to-ansi-or-posix C src, like lua's, or your dns.c
requires only to know how to call cc, but those aren't the cases I'm
interested in. I'm interested in code that is not so trivially
portable.

> whatsoever. The makefile's only job is to figure out how to invoke the
> compiler and linker properly.

I see no sign that of support for epoll in the socket code in your
libdns/contrib/ directory.

Also, avoiding support in your build system for finding dependencies
by just including the dependencies in your project is certainly one
way to go, but its not what I want to do.

> I see that libnet supports OSF/1 and Windows, and like I said before once

But not with autotools, I don't think, it has seperate windows build
files. No idea if they even work, but I haven't gotten any bug
reports. I don't even pretend to test libnet on its myriad platforms.

Sam