Created attachment 160 [details]
Common dynamic library support

Okay, as usual, I went overboard with this one.

Since the recent "compile time validation of function prototypes for external dynamic libraries" worked well for FFmpeg, I thought it might be good for Lame as well.  In addition, I'd found that searching for Lame and FFmpeg used different semantics.  So, I figured a common handler for dynamic libraries was in order.

This patch adds a new DynamiLibrary class that provides consistent path searching, consistent "Find Dialog" handling, and compile time prototype validation for function.

The Lame and FFmpeg library code was reworked to use the new class and to provide the ability to have multiple search paths and library names.  This allows for easier changes to installation locations and also allows for using the libmp3lame library built for use with FFmpeg.  A single "Libraries for Audacity" installer could then be provided to make it easier for users to add Lame and FFmpeg support.

In addition, the FFmpeg loading has been made more dynamic and now will recognize newly installed libraries while Audacity is still open.  (The whole point of this bug.)

I'm pretty sure this will need more work, like reworking the log messages and comments, so I wouldn't consider it final.  I just wanted to get it posted for some testing and review.

Thanks, Leland. When I test this I'll give my views on your off-list questions too.

(In reply to comment #2)
Leland,

I tried your patch just on Win 7 so far. I tested the steps to repro which were OK using FFmpeg 0.6.2. Then I uninstalled 0.6.2, initialised .cfg, pointed Prefs to an FFmpeg 0.5 which was not installed, quit and restarted Audacity. Then I installed 0.6.2 and pointed Prefs to it. That also worked OK, the 0.6.2 libs were used.   

The new code is less tolerant of a misnamed lib. If I rename avformat-52.dll to "avormat-52.dll", quit/restart Audacity so this path is in .cfg, then import a WMA, I will be shown the "Locate FFmpeg" dialogue.I can OK the path and import the file, but I will be shown the dialogue again on next WMA import. Using Prefs to browse to and open "avormat-52.dll" shows valid lib numbers, but doesn't stop the behaviour when I import. If I then browse from Prefs, open "avcodec-52.dll" instead and click OK on "Locate FFmpeg", I just get thrown back to "Locate FFmpeg" in an endless loop without explanation. The current code will take me back to Prefs where I can at least see "FFmpeg library not found". 

I think the filter in browse should therefore default to "only <relevant lib>" and not "FFmpeg Library". I guess you saw it on the Forum but with the old code, Bill says on Mac that there is no "only avformat.dylib" filter. 
 
Also I note in the patch 

+   return wxT("/Library/Application Support/audacity");

Does this give us "/Library/Application Support/audacity/libs" which I think we agreed was better than having lib files in with .cfg files? 

Despite a few minor issues I would like this in 1.3.14 because of the OS X problems with the current /usr/local/lib installation path.

----

Leland wrote (off-list) 
> 1)  When you "Find" a library and return to the Preferences dialog, you 
> can't click the dialog's cancel button and discard the change you just made.
I don't really care "that" much. You can cancel in the current "Locate" dialogue. 

> 2)  When you "Find" a library and it is an older Blade API only library, 
> the warning message appears AFTER the Find dialog is dismissed.  I think 
> the message should display while the Find dialog is still active to give 
> the user another chance...ya know, typical error handling.
I don't think it's "that" bad relative to how often it happens. 

> 3)  Once you "Find" a library, the only way to "unfind" it is to edit or 
> delete audacity.cfg.  I think there should be a "Reset" button or something.
Similar comment to 1) but yes I think there is a case for an option to remove the "LibPath" in Prefs - maybe a "Delete Path to Library (effective after restart)" checkbox. Might be hard to get it across to users - it could mean there will be no LAME/FFmpeg support, or it could mean that support will revert to a copy of the libs in the "expected" place. Note this proposal to have a global reset of cfg:
http://wiki.audacityteam.org/wiki/Proposal_Easy_cfg_Reset

I think all the above would be *far* simpler if we built the "Locate" dialogues into the Libraries Preferences. The current "Locate..." button in Prefs would do what "Browse" in the "Locate..." dialogue does. The only extra we need is that prefs would display the current path to the lib as dynamic text. IMO this would be much better than the complex "Locate" dialogue with the "editable" text box which doesn't work - you still have to browse and open. The "library not found" text opposite "library version" in Prefs could perhaps display "Incompatible - choose "Download" to obtain latest version" instead of (or as well as) having an alert for it.    

An objection might be what would happen when you import/export a file with the libs not found. I think it would still be cleaner and more intuitive to open the Libraries Prefs with the relevant "Locate.." button selected - especially if the current text that goes alongside the lib numbers can be made more informative. If not, why not keep the "Locate" dialogues just for when an import/export can't find libs? 

A small point for those who like to fiddle around in cfg - I think it's confusing to have no libpath entry when the expected path is found.

Created attachment 173 [details]
Fixes a couple of problems

This should correct the problems you found Gale.  Let me know if not....

My recent testing with a Guest account on a Macbook Pro running Sierra did not encounter this issue with:

a) 2.1.2
b) jc10
c) 2.1.3 alpha nightly 06Jan17

With all three tests the Mac was cleaned of Audacity by logging out of the Guest account.  Audavity installed and left running as the installation was effected from Preferences.