Didier sent me an email last week (which unfortunately took me a while to get to), asking a simple question:
I also would like to add colour to test results (color-tests option), but it seems to be only supported in automake >= 1.11 according to http://www.mail-archive.com/automake@gnu.org/msg14979.html .
Do you know a way – such as the one for the silent rules – to enable this option in a compatible way for both 1.10 and 1.11 versions ?
He’s referring to the way I documented using optional silent rules so that you can use silent rules on automake 1.11 without breaking when using an older automake version, such as 1.10. This is one of the most linked snippets of my guide, because many people are interested in having silent (cleaner) rules by default, but they can’t afford to require their users to update automake just because of that (heck, there are a number of projects stuck to automake versions even older than 1.10, for compatibility with older distributions such as RHEL5). Having optional, auto-discovered silent rules fit most uses without trouble.
Now, Didier is asking for similar conditions to make use of coloured test output, which should make it easier to interpret when looking at the output (at least interactively over a terminal, as coloured output in log files becomes harder to read, I have bad experiences on the tinderbox with packages that always use colours.
Anyway, since this is a similar issue to the silent rules, it’s definitely not worth overdoing by requiring automake 1.11 just for this feature. Unfortunately, it’s not possible to have a clean solution to this. You’d expect that the automake developers, knowing all too well that most projects don’t want to force newer automake version requirements, would have added a definition, or a macro, to test for the automake version in use, allowing for conditional code depending on the version. Unfortunately, that’s not the case; the only macro that might seem like doing that is the AM_AUTOMAKE_VERSION macro, but it’s not what you think it would be:
# (This private macro should not be called outside this file.)
..
dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
dnl require some minimum version. Point them to the right macro.Sigh.
Anyway, since you cannot use a conditional on the version you got to look for an alternative approach. In the case of silent rules, my solution was to check for the definition of the AM_SILENT_RULES macro itself: beside the option to AM_INIT_AUTOMAKE, for silent rules you have the ability to either enable them by default or not, and to do that, you’re given the eponymous macro. While I would have thought the same type of conditional would be feasible for the coloured tests, it turns out it’s not the case.
While the two clean options (checking for automake minimum version, or checking explicitly for the color-test feature availability) are not available, we are not entirely stuck. We can use a dirty hack: since we know that the coloured test output and the silent rules were implemented at the same time, we can simply check on whether silent rules are available, and if they are, enable coloured tests as well. But, you cannot expect automake to make it easy to implement this check either! Indeed, because of how aclocal is implemented, m4_ifdef is going to succeed only if the macro is going to be called, even if just conditionally. This works out properly for the conditional silent rules, since your target is to call that, at the end. If you consider your target here to just set color-test, you’ll definitely fail. You have to get both features at once, for it to work:
m4_ifdef([AM_SILENT_RULES],
[m4_define([myproj_color_tests], [color-tests])],
[m4_define([myproj_color_tests], [])])
AM_INIT_AUTOMAKE([foreign ]myproj_color_tests)
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES])Yes, this is definitely nasty, tricky, dirty, and unreliable, since we can’t know whether in the future one of the two features is going away, or maybe even become the default. Without a proper version identifier or an official way to enable features only if available, we’re basically stuck. We should probably complain with automake upstream until they can actually provide us with the needed features to test for this. Not that I’m positive that’ll happen anytime soon.
So while I could tell you how to do this, I’m going to positively recommend against this, and I won’t document it on Autotools Mythbuster proper.