[Libvir] [PATCH] Avoid compile failure when HAVE_AVAHI is not defined.

Daniel Veillard veillard at redhat.com
Mon Dec 3 16:49:42 UTC 2007


On Mon, Dec 03, 2007 at 02:36:17PM +0100, Jim Meyering wrote:
> Without this patch, building without HAVE_AVAHI fails due to an unguarded
> use of mdns_name.  Rather than adding yet another #ifdef..#endif (ugly
> and less maintainable), I've chosen to un-ifdef the declarations and
> a few uses.  The more code that we compile and use unconditionally,
> the fewer surprises we'll encounter down the road.
> 
> Mon Dec  3 14:24:20 CET 2007 Jim Meyering <meyering at redhat.com>
> 
> 	Avoid compile failure when HAVE_AVAHI is not defined.
> 	* qemud/qemud.c (remoteReadConfigFile): Remove some of the
> 	"#ifdef HAVE_AVAHI" guards around uses of mdns_name and mdns_adv.

  I tend to disagree. If we know at compile time that some code should
not be included, then we should not do it. Sometimes there are better
solutions to this problem than an explosion of #define/#endif but 
it's the most common way unfortunately. What we can do is try to isolate
into function specific (or even better module specific) the parts which
are really dependant on a single feature.

  To me usually a single level of define in a function is relatively
maintainable long-term, things like

int operation_foo(...) {

   ....
#ifdef HAVE_BAR
   ...
   do_some_bar_stuff()
   ...
#else
   do_something_else()
#endif

   ....
}

   looks okay to me. The problem arise when we start to see imbricated
#ifdef/endif blocks, IMHO this usually means that the function should be
broken into smaller chunks which addresses more specific subpart of the
task. A bit like when indenting starts to force you to write code which
doesn't fit in 80 columns, same kind of problem, same kind of solutions.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/




More information about the libvir-list mailing list