[FFmpeg-devel] [PATCH] small configure simplification

[Måns Rullgård]

Aurelien Jacobs <aurel at gnuage.org> writes:

> On Tue, 21 Aug 2007 00:46:44 +0200
> Aurelien Jacobs <aurel at gnuage.org> wrote:
>
>> On Mon, 20 Aug 2007 23:25:22 +0100
>> M?ns Rullg?rd <mans at mansr.com> wrote:
>> 
>> > Aurelien Jacobs <aurel at gnuage.org> writes:
>> > 
>> > > Hi,
>> > >
>> > > The attached patch simplify configure using the new $COMPONENT_LIST.
>> > > Ok to apply?
>> > >
>> > > Aurel
>> > >
>> > > Index: configure
>> > > ===================================================================
>> > > --- configure	(revision 10153)
>> > > +++ configure	(working copy)
>> > > @@ -995,11 +995,9 @@
>> > >    --disable-protocols) disable $PROTOCOL_LIST
>> > >    ;;
>> > >    --enable-*=*|--disable-*=*)
>> > > -  eval `echo "$opt" | sed 's/=/-/;s/--/action=/;s/-/ thing=/;s/-/ name=/'`
>> > > -  case "$thing" in
>> > > -      encoder|decoder|muxer|demuxer|parser|bsf|protocol) $action ${optval}_${thing} ;;
>> > > -      *) die_unknown "$opt" ;;
>> > > -  esac
>> > > +  eval `echo "$opt" | sed 's/=/-/;s/--/action=/;s/-/ thing=/;s/-/s name=/'`
>> > > +  is_in "$thing" $COMPONENT_LIST || die_unknown $opt
>> > > +  $action ${optval}_${thing%s}
>> > >    ;;
>> > >    --enable-?*|--disable-?*)
>> > >    eval `echo "$opt" | sed 's/--/action=/;s/-/ option=/;s/-/_/g'`
>> > > @@ -1796,18 +1794,16 @@
>> > >      echo 'asm (".align 3");' | check_cc && asmalign_pot="yes"
>> > >  fi
>> > >  
>> > > -enabled_any $ENCODER_LIST  && enable encoders
>> > > -enabled_any $DECODER_LIST  && enable decoders
>> > > -enabled_any $MUXER_LIST    && enable muxers
>> > > -enabled_any $DEMUXER_LIST  && enable demuxers
>> > > -enabled_any $PROTOCOL_LIST && enable protocols
>> > > -enabled_any $BSF_LIST      && enable bsfs
>> > > -
>> > >  enabled_any $THREADS_LIST  && enable threads
>> > >  
>> > > -check_deps $CONFIG_LIST $HAVE_LIST $DECODER_LIST $ENCODER_LIST $PARSER_LIST \
>> > > -    $BSF_LIST $DEMUXER_LIST $MUXER_LIST $PROTOCOL_LIST
>> > > +for component in $COMPONENT_LIST; do
>> > > +    LIST_NAME=`toupper ${component%s}`_LIST
>> > > +    eval enabled_any \$$LIST_NAME && enable $component
>> > > +    eval check_deps \$$LIST_NAME
>> > > +done
>> > >  
>> > > +check_deps $CONFIG_LIST $HAVE_LIST
>> > > +
>> > >  enabled libogg    && append pkg_requires "ogg >= 1.1"
>> > >  enabled libtheora && append pkg_requires "theora"
>> > >  enabled libvorbis && append pkg_requires "vorbis vorbisenc"
>> > > @@ -1975,14 +1971,11 @@
>> > >  
>> > >  print_config ARCH_   $TMPH config.mak $ARCH_LIST
>> > >  print_config HAVE_   $TMPH config.mak $HAVE_LIST
>> > > -print_config CONFIG_ $TMPH config.mak $CONFIG_LIST   \
>> > > -                                      $DECODER_LIST  \
>> > > -                                      $ENCODER_LIST  \
>> > > -                                      $PARSER_LIST   \
>> > > -                                      $BSF_LIST      \
>> > > -                                      $DEMUXER_LIST  \
>> > > -                                      $MUXER_LIST    \
>> > > -                                      $PROTOCOL_LIST \
>> > > +print_config CONFIG_ $TMPH config.mak $CONFIG_LIST
>> > > +for component in $COMPONENT_LIST; do
>> > > +    LIST_NAME=`toupper ${component%s}`_LIST
>> > > +    eval print_config CONFIG_ $TMPH config.mak \$$LIST_NAME
>> > > +done
>> > >  
>> > >  if test "$targetos" = darwin; then
>> > >    echo "#define CONFIG_DARWIN 1"  >> $TMPH
>> > 
>> > This adds a level of indirection only to marginally reduce the amount
>> > of code.  The new versions is probably slower too.  I don't like it.
>> 
>> I admit I havn't benchmarked it... but I doubt there is any significant
>> speed difference (at least with any decent shell).
>> The advantage here IMO is not the amount of code, but the reduced
>> duplication. Now, when we will have to add a $AVFILTER_LIST, we will
>> have to add it at dozen of places in configure. This patch simplify
>> addition of new kind of "component". Don't you think it's worth ?
>> 
>> BTW, where your comment related only to the end of this patch or also
>> to the first hunk ?
>> 
>> Anyway, attached a new patch containing further simplifications.
>> Please tell me if at least the first hunk is acceptable.
>
> No comments ?
> Well I will apply only first hunk very soon.

I already rejected this.  Do not apply it.

-- 
M?ns Rullg?rd
mans at mansr.com