checking for the existence of a given package is usually not a good idea, as it relies on specific distributions (e.g. Fedora) and specific package names (e.g. libc6-dev-i386); other distributions (or other versions of the same distributions) will have different package names and tools to interact with the package manager (e.g. apt vs rpm vs ...)
the well-established autotools way is to run tests for the things that you actually need (e.g. include a given header file) rather than check for things that might provide the things you need (e.g. a certain package)-
e.g. if your actual code requires to include features.h, then you should test (in a pre-build step) whether it is possible to include this file without errors.
the following autotools example will stop with an error if features.h cannot be used; which allows the user to fix the problem by installing the correct packages (e.g. as hinted in your README) before starting a time-consuming build process.
#snippet from configure.ac
#stop configure process if we cannot use foo.h
AC_CHECK_HEADERS([foo.h],,AC_ERROR([cannot include foo.h - try installing libfoo-dev])
if instead of failing the configure step you would rather simply disable parts of your build, you might want to do something like this:
configure.ac:
have_bar_h="no"
AC_CHECK_HEADERS([bar.h],[have_bar_h="yes"])
AM_CONDITIONAL([BAR]) [ test "x${have_bar_h}" = "yes" ]
and Makefile.am
if BAR
# only do the 32bit build if we have bar.h
bin_PROGRAMS+=coolapp32
ebduf
sorry that this answer is very autotools specific, but i'm sure that waf has similar ways; check the section about Configuration helpers in the WAF documentation.
