ludo@gnu.org (Ludovic Courtès) writes: >> - It tries to find libid3tag and libmad via pkg-config even though they >> don't install .pc files. Perhaps we can generate them manually in the >> install phase of those packages, or maybe they just don't get >> installed due to a bug. Perhaps they just need 'pkg-config' as an >> input? I might try that next. > > That would be surprising. Perhaps the Audacity developers were using a > distro that adds .pc files for these two libs? Apparently Debian indeed adds .pc files. I added patches to them to do the same. >> - Audacity apparently uses PortAudio version 19, but the in-tree one has >> a function which the upstream one doesn't. It would be strange if >> they had an API change without changing the version, so no idea what's >> going on there. > > Could you try to find out what the story of this function is? It would > be best to avoid using the bundled PortAudio. Apparently it's from a patch that has been waiting forever to be merged into PortAudio and it's questionable whether it ever will. I applied it to our PortAudio package. >> - Dynamic loading of FFmpeg fails and I couldn't figure out why (it >> didn't print any errors when I ran Audacity and normally it's pretty >> verbose) so I just passed --disable-dynamic-loading and it was fine. > > OK. By the way this came out to be a known problem among Audacity folks. >> - The test suite fails due to some missing portaudio.h file. I didn't >> come far trying to figure out why this happens so I just disabled the >> test suite. > > Perhaps that problem would magically vanish when using system’s > PortAudio because headers would be in $CPATH. Indeed. Sadly the test suite seems to have other issues, and I've been told it isn't "well exercised" so I disabled it for now. (FWIW it also fails in the upcoming Audacity 2.1.0 which is now entering RC2 phase and will be released soon.) > The rest of the patch looks good to me; just the PortAudio issue needs > to be resolved. Updated patches below. Note also it's in audacity.scm now and not audio.scm, because it depends on ffmpeg, which is in video.scm, which now imports audio.scm, so audio.scm cannot import video.scm. We might want to just wait for 2.1.0 to be released by the way, since it should be out in a couple days. The FFmpeg dynamic loading and test suite issues aren't resolved, so the only difference will be the version; feel free to review this patch as if it were for 2.1.0.