Re: alsa support does not compile

The patch does not work with my library version. With it `SND_LIB_VERSION' remains undefined. It is defined in 'alsa/version.h', but this file is not included by the source, directly or indirectly. Why check library version explicitly instead of check for its interface itself? Always a library can appear that <is hybrid or customized> (from <(autoconf) Introduction>) and does not obey the assumed version conventions, but is still correct in that in one or another way it is compatible with some original library version. This is exactly what autoconf is for. If there is too many variants of library interface to write checks for, that is, the library is that unstable, why use it at all? When an "official" do-it-right header (the comment suggests it is `alsa/asoundlib.h' in this case) is not included, the program thus tries to rely on library internals and is always prone to failure. In my version `#include <alsa/version.h>' before other alsa ones works, in other ones it may just not exist. The comment also says why `alsa/asoundlib.h' is not included. Do alsa maintainers have a bug report so that it is fixed in some next version? Is there a published copy of that report? Redefining these preprocessor symbols by alsa headers is also checkable. If we know (from these checks) exactly what symbols it tries to redefine, a workaround should be possible. What about adding both? What is the alsa version that suffers from all of that? With mine, after wrote sole #include <alsa/asoundlib.h> do not getting any preprocessor symbol redefinition warnings. Does the broken version `#undef' them first, and that redefinition (potentially) breaks other things? If yes, what is broken? Moreover, this way xemacs with alsa sound enabled builds normally.