[MPlayer-dev-eng] [RFC] de-autoconf configure

[Diego Biurrun]

On Wed, May 10, 2006 at 09:00:53PM -0400, Rich Felker wrote:
> On Thu, May 11, 2006 at 12:09:52AM +0200, Diego Biurrun wrote:
> > On Wed, May 10, 2006 at 06:04:15PM -0400, Rich Felker wrote:
> > > 
> > > I'll add myself as against it. Making output 'different for the sake
> > > of being different' is at worst confusing to users and at best a waste
> > > of time. An autoconf replacement is probably the most useful if it
> > > looks mostly/entirely the same to users (who are already used to
> > > autoconf) but works much better inside.
> > 
> > No, that cannot work because the semantics are _fundamentally_
> > different.
> 
> Can you explain the fundamental difference to me? I only know two
> major differences:
> - unknown options are errors
> - enable means force (which usually doesn't even work)
> 
> I don't see these as fundamental and I don't see how they cause
> significant problems.

That enable means force is quite significant.  This way compilation may
fail, even if configure ran successfully.  Also, we do not bail out when
some prerequisites for compilation are not met.

People attribute this to a bug in MPlayer even though it may have been
a user error.

> > burnt.  There is no good way to tell at a glance (without reading the
> > source) that it's a different thing.
> 
> Reading the README?

Currently nothing in configure makes it clear that we do not use
autoconf.

> > > And I agree with Ivan that there are a lot more important things (like
> > > cvs->svn) to finish!
> > 
> > This has nothing to do with cvs->svn.  I made this in a few spare mins I
> > had at some point weeks ago and just now sent it here.  cvs->svn is a
> > process for which I need to find a long stretch of uninterrupted time.
> > Unfortunately this is hard to come by at the moment.
> 
> I agree. Also I want cvs->svn done _right_, not quick-and-dirty.
> However my point was that this configure thing, which was supposed to
> be a small issue finished in a few minutes, has grown into something
> much bigger and it's wasting time.

It's a bikeshed topic :-/  Just look how much Enrico has to contribute
to it...

Usability issues are inherently bikeshed material because it's easy to
form an opinion on them (not necessarily good or correct, though).  That
does not, however, make the points invalid.

Diego