[MPlayer-dev-eng] [PATCH] clean up tests in configure
Diego Biurrun
diego at biurrun.de
Tue Jul 5 02:42:15 CEST 2005
On Mon, Jul 04, 2005 at 10:30:42PM +0300, Ivan Kalvachev wrote:
> On 7/4/05, Diego Biurrun <diego at biurrun.de> wrote:
> > > I think this is enough reason to reject the patch.
> >
> > I disagree unless you can come up with a case where this might fail in
> > practise and not just in theory.
> >
> > > As for the rest of 'cleanups' I think that they could be trown away in
> > > favor of the proposed change from () to {} . {faster speed while more
> > > readable}.
> >
> > I think the other changes apart from -a/-o and uncontroversial so I'll
> > apply these anyway.
typo: s/and/are/
> And I will revert it.
> This patch doesn't do anything else than obfiscation.
>
> DonDiego don't boss around you are not the MPlayer team.
> These kind of things cannot be desided only by you and you are not the
> one that have the finnal word.
The same applies to you so please don't start flaming.
I surely wasn't trying to "boss around" anybody and I don't think I did.
Maybe I was just unclear, so I'll try to find better words now:
-a/-o vs &&/||:
===============
You say that
1) -a/-o is less readable (even "obfuscated"),
2) the possibility for ambiguity with -a/-o is reason enough to reject
the patch.
I disagree on both counts since
1a) -a/-o is shorter (and IMO this aids readability on long lines),
1b) -a/-o avoids another test invocation and should thus be faster,
1c) after a short time of getting used to it -a/-o should be equally
readable for everyone.
2) I don't think we run the risk of ever hitting that ambiguity and
1a-c) might be a real gain in practise.
Speed will have to be measured. We might be talking about unnoticeable
gains or even nothing at all. Then again it might be real.
subshells etc:
==============
The patch in question consists of basically two parts
a) &&/|| --> -a/-o
b) removing subshells and other small speedups/simplifications
My understanding was that only a) was controversial and thus I wanted to
commit b) alone. I think at this point nobody is 100% certain what b)
really consists of, so I'll split it off and propose it separately.
We'll see whether or not it is problematic then.
Diego
More information about the MPlayer-dev-eng
mailing list