On Sun, Apr 12, 2015 at 11:56:30AM +0200, Janne Grunau wrote: > 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.
I still don't think it's a problem worth worrying about in practice. Maybe somebody else can weigh in to convince me? Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
