On 2015-04-09 18:44:59 +0200, Diego Biurrun wrote: > 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 <[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. > > Yes of course, but I see nothing unpredictable there.
unpredictable is maybe the wrong word if you assume knowledge of configure / the build system. It creates build ebviroment dependent binaries without explicit control from configure. That's enough reason to avoid it for me. If you're concerned about the length/details of the $(configure --help) output, we can think about adding --help=full and move more obscure options there. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
