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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
> 
> 	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@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]