[MPlayer-dev-eng] [RFC] configure2 underway

pl p_l at tfz.net
Thu Nov 15 14:00:38 CET 2001


Hi,

As some (any) of you may be aware, as time goes on, the configure script
becomes a real pain to extend:
  - where do I add my stuff ?
  - several parts to modify in the scripts:
      before args parsing
      after
      default values
      tests
      C and makefile #ifdef -llibfoo generation
  - no common naming style : sometimes _symbol is a yes-no-other value,
    sometimes it becomes a '#ifdef fooo' sometimes it's a library


I've started cleaning things up so as to gather things a bit and make it
cleanier:

  - preparsing: set standard default values: yes no auto
  - options parsing: add the --enable-opt and --disable-opt in a row
    Such options forces a value and disable the auto checks
    (The l^huser knows what he does)

  - test blocks handle 1 functionnality and look like:

    echo -n "checking opt ..."
    if test "$_opt" = auto ; then
       # do C check here or whatever

       $_opt=no
       testsuccess && $_opt=yes
    fi
    if "$_opt" = yes ; then
      _def_opt='#define HAVE_OPT 1'     # or #define USE_OPT 1 or
					# whatever is used for this 
					# peculiar option
      _inc_opt=' -I/usr/foo/bar/include '
      _ld_opt=' -L/usr/foo/lib -lopt '
    fi
    echo "$_opt"

  - defines naming style for include or gcc flags

  - You have a progressive test that is run (a la GNU autoconf) and not
    a "please wait" followed by a burst of 50 lines indicating the
    result.

Notes:
~~~~~~
I won't commit to CVS till it works (at least for me :) :
 - it is broken (does not generate correct config files)
 - it has no longer any common architecture bigger than blocks with
   standard configure so the diff is really huge
 - I do _not_ want bugreports right now till it's not working/cleaned 
   the way I want
 - even if I commit to configure2 they're will be much useless commits
   since many parts are still "dirty"

It has been a fork of sunday's version so the options added since that
have not yet been added.

I think it is cleanier and simpler but that's only my view so...
I attached a snapshot of my file asking for the judgement of the MPlayer
-dev.

The snapshot just performs tests and create config files (they're not
usable yet).


What I expect now is : a "Go ahead !" or a "Forget that !" reply.
(No bugreports please)

Of course criticisms are welcome (ahem... ;)

--
"Janitor-ly" yours,
  pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure2.gz
Type: application/octet-stream
Size: 18920 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20011115/f332b207/attachment.obj>


More information about the MPlayer-dev-eng mailing list