On Thu, Apr 09, 2015 at 12:39:33AM +0200, Janne Grunau wrote: > On 2015-04-07 14:38:59 +0200, Diego Biurrun wrote: > > On Tue, Apr 07, 2015 at 10:22:16AM +0200, Luca Barbato wrote: > > > On 06/04/15 23:28, Vittorio Giovara wrote: > > > >On Sat, Apr 4, 2015 at 6:43 PM, Diego Biurrun <di...@biurrun.de> wrote: > > > >>On Thu, Apr 02, 2015 at 01:55:26PM +0200, Vittorio Giovara wrote: > > > >>>On Thu, Apr 2, 2015 at 1:20 PM, Diego Biurrun <di...@biurrun.de> wrote: > > > >>>>>--- a/configure > > > >>>>>+++ b/configure > > > >>>>>@@ -315,6 +315,8 @@ Developer options (useful when working on Libav > > > >>>>>itself): > > > >>>>> (group) and PROB the probability > > > >>>>> associated with > > > >>>>> NAME (default 0.5). > > > >>>>> --random-seed=VALUE seed value for --enable/disable-random > > > >>>>>+ --disable-valgrind-backtrace do not print a backtrace under > > > >>>>>Valgrind > > > >>>>>+ (needs --disable-optimizations) > > > >>>> > > > >>>>I don't like this. Why not automatically enable it when optimizations > > > >>>>are disabled instead? > > > >>> > > > >>>It is automatically enabled when optimizations are disabled, I just > > > >>>added some help text because users could wonder why it's not enabled > > > >>>(eg. they do need to disable optimizations). > > > >> > > > >>The text is still confusing. But before fixing that I think we should > > > >>consider enabling this unconditionally if optimizations are disabled. > > > >>What's the point of having a disable switch for this? (We already have > > > >>far too many configure parameters.) > > > > > > > >I think it was to stifle any concern for packagers having to deal (or > > > >not) with this feature. > > > >I am completely fine with removing the additional switch. > > > > > > As one of the concerned packager I'm against removing it, builds must be > > > predictable. > > > > How is a build w/o this new parameter unpredictable? > > it enables/disables the feature depending whether the build enviroment > has a proper valgrind/valgrind.h header.
Yes of course, but I see nothing unpredictable there. > It's configurable solely by having the variable in $CONFIG_LIST whether > we keep this help parameter or not though. If the variable remains (in CONFIG_LIST), it must be documented (properly). My suggestion is to get rid of it entirely, however. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
