[FFmpeg-devel] [patch] allow build env to force sdl-config path via $SDL_CONFIG
Sat Feb 16 04:08:31 CET 2008
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
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
> > > 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
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel