[FFmpeg-devel] [patch] allow build env to force sdl-config path via $SDL_CONFIG
Sat Feb 16 04:30:58 CET 2008
On Feb 15, 2008 10:08 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Feb 15, 2008 at 09:11:59PM -0500, Mike Frysinger wrote:
> > > 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
which users are you referring to ? the imaginary ones that have
forced the existing ffmpeg configure system to the state that it's in
now (which mimics the standard autoconf configure script) or the
imaginary ones for all the other home brewed build systems ? does it
really matter ?
> > > > 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.
which is irrelevant on systems which do not allow non-PIC in shared
(or even non-shared) objects.
> > 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),
you're looking at architectures (most of which imply Linux), not
operating systems. as you say, recent-POSIX systems are of value.
anything older an ffmpeg will not configure/build.
> > > > 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
you've left out "anymore" in that statement.
ive looked through the latest version of configure in svn trunk and it
is certainly much tighter than the last time i looked. most of the
behavior i had to patch around has been replaced with
traditional/expected behavior. which is to say the current result
mimics a standard autoconf script fairly well.
More information about the ffmpeg-devel