Notice: register_sidebar was called incorrectly. No id was set in the arguments array for the "Sidebar 1" sidebar. Defaulting to "sidebar-1". Manually set the id to "sidebar-1" to silence this notice and keep existing sidebar content. Please see Debugging in WordPress for more information. (This message was added in version 4.2.0.) in /usr/share/wordpress/wp-includes/functions.php on line 4139 Tech Notes » patch

Nagios Can Survive AutoHeader

patch No Comments »

What does it mean to survive autoheader? Portability, easier maintainability.

BTW: The patch is right here: nagios-autoheader.patch

Autoheader is a tool that creates the header file associated with autoconf-generated configure; autotools (ie autoreconf) tend to assume that if you’re using AC_CONFIG_HEADERS(), you have a header file generated from your configure.in or configure.ac.

FWIW, Nagios’ use of AC_CONFIG_HEADER(file1 file2 file3) is actually converted to AC_CONFIG_HEADERS(file1), but not using the plural makes it confuse autoheader a bit.

Consider that maintaining twenty files is more difficult than maintaining one; maintaining two files is only slightly more difficult, but still is an entry-point for human error.

Just like driving on the left (former British colonies, for example) is more difficult after driving on the right (everywhere else); for the same reason, doing things in a way that differs from the mainstream is more difficult for others — who are used to the mainstream — to adapt to. The corollary to this: approaching the mainstream way allows more developers to maintain your work.

The other benefit of joining the mainstream is that you gain from how the mainstream has “moved on”, and developed added benefits and utilities. For example, automake reduces the maintenance of makefiles, and gives you “make dist”. Nagios has a bunch of unusual scripts ot maintain versions of things, but Autotools do that by defining in the configure.in and substituting at ./configure time. This ties into the “maintaining fewer files” above as well as doing things in the conventional manner.

Note that it makes no difference whether a project has done it a certain way since USL times — a new user sees it for the first time only when they first see it, with no regard for how long it’s been like that. This is to say that if it looks broken when the user first starts to work with it, it doesn’t matter how long it’s been broken, or if that method wasn’t considered “broken” when filing a stack of cards for batch-processing.

The small change I’ve done today allows Nagios to approach the current conventional method, and opens the path for further enhancements in a step-by-step progression of little changes at a time.

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in