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

[Mike Frysinger]

On Fri, Feb 15, 2008 at 8:31 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Feb 15, 2008 at 07:55:37PM -0500, Mike Frysinger wrote:
>  > On Fri, Feb 15, 2008 at 7:27 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
>  > > "Mike Frysinger" <vapier.adi at gmail.com> writes:
>  > >  > On Fri, Feb 15, 2008 at 4:33 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
>  > >  >> "Mike Frysinger" <vapier.adi at gmail.com> writes:
>  > >  >>  > On Thu, Feb 14, 2008 at 6:39 PM, Diego Biurrun <diego at biurrun.de> wrote:
>  > >  >>  >> On Wed, Feb 13, 2008 at 10:42:43PM -0500, Mike Frysinger wrote:
>  > >  >>  >>  > as is standard with pretty much all autotool-based build systems which
>  > >  >>  >>  > search for the sdl-config script, this patch allows people to force
>  > >  >>  >>  > the full path to sdl-config via the SDL_CONFIG env var.  so now you
>  > >  >>  >>  > can do:
>  > >  >>  >>  > SDL_CONFIG=/some/crazy/stupid/place/sdl-config ./configure
>  > >  >>  >>  > and ffmpeg will find the crazy stupid sdl
>  > >  >>  >>  >
>  > >  >>  >>  > --- configure (revision 11931)
>  > >  >>  >>  > +++ configure (working copy)
>  > >  >>  >>  > @@ -1693,7 +1693,7 @@ check_foo_config freetype2 freetype ft2b
>  > >  >>  >>  >
>  > >  >>  >>  >  disable sdl_too_old
>  > >  >>  >>  >  disable sdl
>  > >  >>  >>  > -SDL_CONFIG="${cross_prefix}sdl-config"
>  > >  >>  >>  > +SDL_CONFIG="${SDL_CONFIG-${cross_prefix}sdl-config}"
>  > >  >>  >>                            ^
>  > >  >>  >>  This '-' looks wrong.
>  > >  >>  >>
>  > >  >>  >>  Also, why can't you simply use PATH?
>  > >  >>  >
>  > >  >>  > the location of the sdl-config wrapper may contain binaries that
>  > >  >>  > cannot be executed on the host.  i dont see why there's any objection
>  > >  >>  > to the change considering this behavior is perfectly standard for
>  > >  >>  > every autotool based package out there that looks for sdl-config.

not that any of this extended thread is relevant in any way to the
original proposition: making the sdl-config script controllable

>  > >  >>  > if you wanted to decrapify the ffmpeg configure script, you'd start
>  > >  >>  > using pkg-config which is much easier to control in a cross-compiling
>  > >  >>  > environment.  then people would only have to set one variable
>  > >  >>  > (PKG_CONFIG) or create one wrapper script (${cross_prefix}pkg-config).
>  > >  >>
>  > >  >>  If you want a nice reception around here, you'd start by not calling
>  > >  >>  the configure script crap.
>  > >  >
>  > >  > it is crap.  any large package that hand rolls their own build system
>  > >  > and forces people to learn their own special conventions that deviate
>  > >  > from every other package out there is crap.  perhaps you could
>  > >  > illustrate in what ways the current situation doesnt suck ?  i'm
>  > >  > really not interested in sugar coating reality so as to make people
>  > >  > feel better about the situation -- they should feel bad.
>  > >
>  > >  Your attitude is the only thing that's crap here.  Well, that and
>  > >  autoconf.
>  >
>  > inability to properly use autotools is what leads to homegrown build
>  > systems
>
>  No you got it wrong, autotools being a tremendously bloated and missdesigned
>  joke.

i'm thinking you take issue with the purpose rather than the design.
the bloat you refer to allows people to target a much wider berth of
systems than ffmpeg's build system could ever touch.  but i doubt that
ffmpeg developers care as the targeted audience of autotool systems is
certainly much larger than the intended audience of systems that will
be compiling/running ffmpeg code.

>  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.

>  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.

>  > that doesnt scale at all.
>
>  Well, any computer ive tried the ffmpeg or mplayer configure scripts on
>  they simply worked. With autoconf based projects spending hours to get
>  them to compile on a common linux x86 system is quite common ...

it's hard to say such an experience is the failing of autotools.  as
you've said, people misusing a tool is the same as a broken tool.

my experience as a package maintainer in Gentoo where i've touched
hundreds of packages across the spectrum is where i draw my views on
things.  sure, when i got started in the Linux world, i thought
autotools was the devil just like everyone else.  it really only took
time playing with all the options and digging into the internals of
things did i appreciate it.

but comparing experiences really isnt worth while.  you've had your
experience, ive had mine, and you probably dont give a damn about
mine.

>  > 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
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
extended system checks and flag handling would have been handled for
free by autotools.  as would have all the cycles spent re-inventing
header/library/toolchain/flag discovery.  and perhaps lost by people
doing it wrong.

> > >  Barging in like this, shouting that everything is crap, you'll only
>  > >  make enemies.  FFmpeg developers have a reputation for being hostile
>  > >  to people far less repugnant than you.
>  >
>  > the fact that the configure script is crap is pretty self evident by
>  > simply reading it.
>
>  ROTFL, you are good, very funny!
>  Though you could try an occasional technical argument.

fair enough.  much of my disgust of late has built up due to digging
through mplayer, but it would seem all the gripes i have with that do
not extend across to ffmpeg.  and the brokenness i experienced with
the last run off ffmpeg has largely been thrown out (requiring
specific cpu/operating systems to be known ahead of time).

>  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
design decisions and goals of autotools however are not intended for
the generated code to be read, so that isnt a complete
apples-to-apples comparison.

>  > it breaks in configurations that differ from
>  > whoever wrote it.  it simply doesnt scale.
>
>  Autoconf scales better, yes, it even breaks in the configuration from the
>  one who wrote it.

again, this gets back to misuse of a tool.  ive written autotool based
packages to build libraries to run on ancient systems of the last
decade+, but such systems (while a goal of mine) are not a goal of
ffmpeg.

>  > 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 ? ;)
-mike