[Dnsmasq-discuss] [PATCH] Add support for autotools

Matthias Andree matthias.andree at gmx.de
Mon Sep 10 16:10:35 BST 2012


Am 10.09.2012 11:27, schrieb Simon Kelley:
> On 09/09/12 06:57, Cristian Rodríguez wrote:
>> El dom 09 sep 2012 02:03:11 CLST, Shantanu Gadgil escribió:
>>> If this is done, won't the autotools chain will be a prerequisite for
>>> dnsmasq to be built.
>>>
>>> Maybe OK for Linux OSes ... not necessary for other platforms/OSes
>>> (think Solaris, AIX, and even more obscure, etc).
>>> Why the overhead?!?
>>>
>>> I really like the *really really simple* Makefile based build and not
>>> at all in favour of this!
>>
>>
>> This **really really simple** makefiles requires constant patching and
>> maintenance for distributions, in short they are a pain in the ass.
> 
> It does? How come I'm not seeing these patches fed back upstream then?
> As the maintainer of the Debian (and therefore Ubuntu) packaging, I
> don't have to patch the makefile.
> 
>>
>> Linux, BSDs, Solaris have automake/autoconf..etc and I could not care
>> less about obscure systems. what matters is  what most people use.
>>
> 
> I wonder how this affects building on Android? Numerically, these days
> that's probably the most important dnsmasq distribution channel.
> 
> It would have been useful to have talked to us before you embarked on
> this work: it's a lot of effort to go to without being sure it's useful,
> but I shall do my best to determine if it improves dnsmasq, without
> being swayed by the sunk-cost.

While I would not accept the migration without a clear and concise
statement of the common shortcomings, why they need to addressed, and
how autotools'ification solves the problems, and the drawbacks, I'd
probably just ignore that.

Now, I have some experience with autotools-based projects, for instance
fetchmail (in fact I added automake for the picture, it was using only
autoconf at the time), and I'd say it is a rather painless process for
end users, and developers, these days.  Avoid Makefile recursion, though
(see Peter Miller's paper why recursive make is considered harmful).


FOR END USERS:

- A project moving to autoconf/automake DOES NOT REQUIRE YOU AS END-USER
to install autotools.

If you have the regular shell utilities such as egrep around, that is
sufficient.

Note that this is in contrast to SCons or CMake - these do require
installations on the end users' systems if end users intend to build the
software themselves


FOR DEVELOPERS:

- you do obviously need to install automake and autoconf, and possibly
gettext.

- bootstrapping a checkout from SVN/Hg/Git/Bazaar/... usually requires
running "autoreconf --install", the rest of your modifications to the
inputs such as configure.ac, or Makefile.in, is handled by the Makefiles
that are present.  In doubt, "autoreconf --install --force" make distclean"

- if someone is in the belief that just autotool'ifying would magically
solve standards violations of your obscure operating system, s/he is
mistaken. This requires spamming the code with #ifdef HAVE_FOO all over,
but this requirement is entirely orthogonal to autotools.

- use "make distcheck" to see if you have listed all files directly
needed to the build in the Makefile.am, and to get a distributable
tarball at the same time.


Having said that, if I were Simon I'd ask for stronger arguments for the
move -- and I have been packaging dnsmasq for FreeBSD; my only concern
is that IDN and NLS are not entirely independent of each other, which is
somewhat harder to present to users.  The whole build setup that I use
is stable, most updates are really just bumping the version numbers and
checksums of download files, so I'd like to see a sensible argument in
Simon's stead.

Of course, if someone migrates dnsmasq just for the fun of it, and as a
case study, there's nothing wrong in that.



More information about the Dnsmasq-discuss mailing list