Re: alsa support does not compile
"Ilya N. Golubev" <gin(a)mo.msk.ru> wrote:
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.
Unfortunately, we had a temporary mailing list outage, so I didn't get
this reply until after committing the other patch. No matter. This is
easily fixed.
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.
Yes, but this is still experimental code. That's why it is on the beta
branch, after all. A recent message tells me that the mixer code is
inappropriate, for example, so I'll have to find a replacement for it.
Note that some of the version-specific code is in there. Also, I have
one machine on which it works great, but I have found another machine
where I am constantly getting "interrupted system call" errors when
attempting to play sounds. I need to track that down. I want to see if
introducing asynchrony is possible. This code is going to remain fluid
for some time until all of these issues are addressed. Until that time,
I don't see the point in spending time writing autoconf checks that
might get discarded when a simple version test will do.
Once the code has settled down and appears stable, migrating to autoconf
checks is the right thing to do for exactly the reasons you list here.
It is just premature right now, in my judgment.
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?
There are 2 variants. Is that too many? And I don't understand what
the number of variants has to do with instability of a library, either.
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?
The header file alsa/asoundlib.h in version 1.0.10 of the library
includes the system <assert.h>. Since we define our own assert macro,
and the glibc 2.4 assert.h, at least, doesn't check whether assert has
already been defined, this leads to a compile error. We cannot just
#undef assert before #include <alsa/asoundlib.h>, because we want our
assert macro, not the system one.
But you are overstating the case. The documentation says that
asoundlib.h is provided as a convenience. It is not documented to be
the sole header file that should be included in all cases. At least, I
fail to see such a statement anywhere in the documentation. Do you? It
can't be anyway, since there are header files in /usr/include/alsa that
are not included by asoundlib.h, nor by anything it includes (e.g.,
pcm_plugin.h for me, version.h for you).
In this case, asoundlib.h is NOT convenient because of the conflicting
assert macros. Therefore, I chose not to use it. This is not an ALSA
bug, so there is no report.
I will fix the version symbol problem in CVS.
Regards,
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University