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 <[email protected]> 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 <[email protected]> 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. It's configurable solely by having the variable in $CONFIG_LIST whether we keep this help parameter or not though. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
