[FFmpeg-devel] [patch] allow build env to force sdl-config path via $SDL_CONFIG

[Michael Niedermayer]

On Fri, Feb 15, 2008 at 09:11:59PM -0500, Mike Frysinger wrote:
[...]
> >  Besides that, it is a security risk due to uncheckable huge configure
> >  files.
> 
> "security" is really a non-existent argument.  anyone worried about
> security would never compile as an account that matters.  anybody who
> would actually be interested in auditing the build system of a package
> would have competent skills to tackle and autotool or the ffmpeg
> system.

We have the skills and time to audit patches to configure, NOONE has the time
to audit the "configure" thing auto* produces. Auditing a small patch to our
configure takes a minute, mere reading through auto* configure would take
weeks, that is even a person who would perfectly understand both would need
a million times longer for auto*


> 
> >  People as you already mentioned also arent good at using autotools, that
> >  means more bugs than there would be with "homegrown" systems. It doesnt
> >  even matter tht much if autotools is bad or people are bad at using it
> >  the result is the same ...
> 
> certainly.  any tool misused is useless.  but spending time to learn a
> build system that solves problems in a consistent manner pays off
> longer than writing a brand new one from scratch.  autotools would be
> a larger burden on the maintainers than the current one, but less of a
> burden on random users.  it seems though that the culture here is
> place emphasis on the maintainers/developers rather than the users.

I never had a problem with any custom configure/make system, i constantly
have problems (as user) with auto*. So from a user POV i would like as
few auto* based projects as possible.

Also iam a little curious, where are the bugreports from all these imaginary
users?

[...]
> >  > just that the alternatives are worse.
> >
> >  Well do you have some argument, a specific usecase which works better,
> >  anything?
> 
> i could mention usecases that involve portability across systems (such
> as generation of proper shared libraries and managing of PIC), but

PIC is a bad idea if you care about performance.


> that wouldnt matter to you as the intended audience of ffmpeg
> developers is quite narrow.  after all, the relevant systems that
> would actually be capable/desirable for doing multimedia playback
> allows for assumption of up-to-date functionality.  all of the

Looking just at the asm optimizations ... ffmpeg must work at least on
x86,ppc,alpha,sparc,arm,blackfin,sh4
Anyway, if you want to compile ffmpeg on a VAX (with some POSIX OS),
just send us a bugreport.


[...]
> >  Here is an example: The fact that auto* is crap is also pretty self evident
> >  by simply reading the output. Just try it, just take occasional pauses, maybe
> >  once per month.
> 
> as a package maintainer, i do read autotool code on a semi-regular
> basis actually (certainly more often than once per month).  the basic

Good then you should be able to finish reading 1 or 2 generated configure
files in your lifetime.


[...]
> 
> >  > if i had the time, i'd assist in
> >  > throwing it all out for something that does scale, but sadly i dont.
> >
> >  > i only have time to extend it slightly when it breaks for me.
> >
> >  Then you must have very little time indeed.
> 
> are you suggesting that switching to autotools would take very little
> time indeed ? ;)

no, iam suggesting that it rarely breaks thus you need very little time
to fix it

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080216/f5eb45ba/attachment.pgp>