[MPlayer-dev-eng] [RFC] configure: print "recommended codecs"
Alexander Strasser
eclipse7 at gmx.net
Sun Dec 2 01:41:38 CET 2012
Reimar Döffinger wrote:
> On Sun, Dec 02, 2012 at 12:55:45AM +0100, Alexander Strasser wrote:
> > Nicolas George wrote:
> > > Le primidi 11 frimaire, an CCXXI, Reimar Döffinger a écrit :
> > > > Audio output: $noaomodules
> > > > Video output: $novomodules
> > > >
> > > > + Recommended codecs: ffmpeg(internal) libopus speex OpenJPEG
> > > > + Recommended video output: opengl
> > > > +
> > > > 'config.h' and 'config.mak' contain your configuration options.
> > >
> > > I do not think that adding to the fixed infodump that nobody reads will help
> > > much. What about this: splitting the enabled / disabled lists into essential
> > > + useful + minute, plus print a warning if an essential component is not
> > > enabled?
> >
> > I do think your patch is OK. Though you might not always need vo opengl
> > but it is for sure the most useful and most widely supported vo if you
> > think cross-platform and modern platform. So "recommended" should be fine.
> >
> > Guess I partly agree with Nicolas that some of that information should
> > be dropped. I particularly think it is *not* a good idea to print one list
> > <enabled things> and then immediately following <disabled things>.
>
> What would the alternative be?
> Only printing one doesn't allow to check if you forgot to enable/disable
> something, doing something like first printing all and then only the
> enabled ones would be worse I think.
Yes, it is not a full substitution information-wise. But I think the
output is just confusing. Also maybe printing all on request (--list-xyz)
would be enough and only printing the enabled ones in the configure summary.
Or even easier it might be already an improvement to first print all
disabled lists and then print all enabled stuff. People (including myself)
tend to focus on the last things printed on their terminal.
> Though I guess at least for an MPlayer-only configuration so few
> libraries actually make sense that the disabled list maybe is pointless.
Alexander
More information about the MPlayer-dev-eng
mailing list