[avahi] Patch: negative results during autoconfiguration would abort ./configure

[Lennart Poettering]

On Sat, 02.09.06 07:20, Adam J. Richter (adam at yggdrasil.com) wrote:

> 	The following patch is related to ticket #34 ("Avahi
> configure script is diffult for things like jhbuld to use",
> reported by james at jamesh.id.au four months ago).  Even though
> I'm logged in to wwww.avahi.org to my newly created account,
> I don't see where I can update the ticket.  Perhaps I'm not
> allowed to, because my account is brand new.  So, I'll post the
> explanation and patch here.

Hmm, that should work fine. I am surprised it didn't work for you. The
accounts should work instantly. Could you please recheck this?

> 	My explanation is kind of long because I think I should
> address to some of the discussion posted to the bug report, in the
> hopes of getting everyone on the same page (although I am glad to
> see that it already is targeted for implementation in 0.7).

The 0.7 milestone is for all kinds of stuff that is on our todo list
but is not high-priority and noone of us is actively working on. It's
more like a "let's not forget this" milestone than something real. For
the near feature we will release only 0.6.x versions. 

In short: unless someone sends us a patch these bug reports are
unlikely to get closed anytime soon. 

In other words: You're work is very welcome.

> 	autocconfiguration scripts are not normally supposed to
> abort when they discover that an optional facility that was not
> explicitly requested is absent.  This way, a larger fraction of

Aren't they? How did you come to that conclusion? Admittedly most
autoconf scripts do not abort in these situations, but Avahi is not
the only package where the autoconf stuff works like it does. (I
cannot refer to another sample right now, but I guess that's because I
usually wait before a software becomes available in Debian before I
try it.)

> potential users can build the source code and find it a worthwile
> trade off of their engineering time.  Also, that way, it is
> possible install new software and then know that it will be
> picked up the next time software packages that use it are
> rebuilt, instead of continuing to be disabled by whatever
> custom build scripts with the extra "--disable-foo" switches
> were put in place in order to get the package to build previously.
> In addition, every time new features are added to avahi based on external
> software, then under the model requiring "--disable", then everybody's
> build breaks on the new release unless they happen to have the software
> used by the new optional feature.

Actually it is my intention to get the people to think before they
update their Avahi installations blindly when Avahi changes its
dependency list. 

I am sure that some people prefer the "automatic" way (like you) and
other people prefer the "non-automic" way á la Avahi, it's a matter of
taste. In fact most distributors don't like the automatic behaviour at
all because it tends to hide errors in their packaging scripts. I
personally tend to agree with them.

I am strictly opposed to "invert" the current behaviour. Some people
would certainly prefer that, others would not. With a situation like
this I see no justification to switch from one extreme to the other.

Avahi is not intended to be compiled by the average user, that's a job
for the distributor. (It's about Zeroconf, don't forget!) If someone
really wants to compile Avahi all by himself he should be able to find
the right configure line for his setup without too much trouble. Avahi
is a system daemon which requires a tight integration into the
distribution. It is not a user application which a user can compile
and use and is fine.

Please understand that I am not generally opposed to have an
"automatic" mode for ./configure, this however should be optional and
not the default. This could be done like the bug report you're
referring to suggests, by passing --enable-foo=auto to ./configure, or
by having a single switch which enables automatic mode for all
dependencies. (which is what Trent suggests with --auto-deps)

> 	Anyhow, here is a patch that fixes the abort that I tripped.
> It does not fix all of the aborts.  It does not fix all such cases,
> but I think it is an incremental improvement, which should help
> make avahi more appealling.

Humm. Besides that the switch from one extreme to the other is not
going to happen I have another issue to point out:

What's the point of renaming HAVE_GLIB to HAVE_GLIB20? That variable
is referred to in the makefiles. Just replacing the names in
configure but not in the Mafefiles will break things. In addition:
we're unlikely to add a glib 1.2 binding, so i don't see the need to
add the version to the variables.

> 	In order to make some of the changes smaller and more
> consistent, I wrote two autoconf macros in a new file common/opt_module.m4.
> They are AVAHI_OPT_MODULE() and AVAVI_OPT_PYMOD.  I am not a very
> experienced autoconf hacker, as you might notice from the fact
> that I have a commented out AC_REQUIRE() call in each of those
> macros that I think is supposed to be there to ensure correct
> dependencies, but somehow breaks things.  Anyhow, I think that
> applying this patch should be an improvement, and then later someone
> can figure out whethere to delete the commented out AC_REQUIRE
> lines entirely or make whatever correction they ideally should
> have.

Making a macro of its own of it is certainly a good idea!

Thank you very much for your patch,
      Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/