On Thu, Jan 31, 2013 at 10:24 PM, Ulrich Klauer <ulr...@chirlu.de> wrote: > Pascal Giard <evily...@gmail.com>: > >> On Wed, Jan 30, 2013 at 10:30 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: >> > For SoX, you should be able to get an idea of API and ABI modifications >> > using "git log -u src/sox.h" since that defines our interface to library. >> > That shows no modifications in dot branch since 14.4.0 release. >> Good! > > This was part of the plan for dot. :-) However, reading section 8.6.2 > of the Policy Manual, I wonder where the difference is between a > library_do_operation() taking an enum and a sox_find_effect() or > sox_effect_options() taking a string. Wouldn't that mean that it is > considered an "ABI change" whenever an effect changes behaviour (e.g., > due to a bug being fixed)?
I think the answer is "it depends". I think it could constitute a modification as defined in section 8.6.2. Could you elaborate on the modifications you have in mind that could constitute a modification please? Based on your judgement, do you think an application using libsox2 could reasonably depend on the previous behavior? >> > I'll have to read up on this new approach. Is it OK to ignore API/ABI >> > changes related to internal-only symbols that we are allowing to leak out >> > (those prefixed with lsx_)? >> Hmm... are we suggesting users to make use of them in some cases? >> Or we're discouraging that practice? > > The latter, I think. This is what sox.h says about it at the moment: >> Symbols starting with "lsx_" or "LSX_" are internal use by libSoX >> and plugins. LSX_ and lsx_ symbols should not be used by >> libSoX-based applications. Fair enough. I feel confortable ignoring lsx_* symbol and ditching them from the autogenerated symbol files. If an app author complains that its applications breaks in connection to an lsx_* symbol having changed, we'll be free to handle the matter as gentleman e.g. 1) Access whether he/she holds a valid use case for that lsx_* symbol; 2) Consider moving it in sox_*; 3) Include that change in a dot release (as it's an addition, not a modif or removal)? >> In any case, why are we "leaking" them? I see there are lots of them, >> they actually constitute the vast majority of symbols! (340/393). > > I'm not sure, but since the library is divided into many compilation > units, we can't simply declare all of those functions static. That > would mean a helper function from effects_i.c couldn't be used from > within spectrogram.c anymore. So removing these symbols would have to > happen at or after linking; I don't know how complicated or easy that > is. I'm not competent enough in the matter to give my opinion on this. However, I see that it's not unusual to leak private symbols so I can live with it. Cheers, -Pascal -- Homepage (http://organact.mine.nu) Debian GNU/Linux (http://www.debian.org) COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca) Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca) ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
