[FFmpeg-devel] [Spam] Re: Fix mingw name of .lib files

Måns Rullgård mans
Wed Mar 5 09:58:01 CET 2008


Gonzalo Garramu?o <ggarra at advancedsl.com.ar> writes:

> Fran?ois Revol wrote:
>>> On Tue, Mar 04, 2008 at 07:53:04PM -0300, Gonzalo Garramu?o wrote:
>>>> I find it funny you hate autotools, as the ffmpeg build smells very 
>>>> much 
>>>> like a simpler (but functionally worse) copy of autotools.
>> 
>> I really smell hard, but I sense no m4, no perl (nothing agains perl by 
>> itself), no autoheader && automake && autoconf && oh-damn-sh*t-I-had-to
>> -run-autobeer-first, no make-"hey why is it running configure again?? 
>> HEY! why is it running autoconf ???? Ohhh * AM_FOO_BAR missing :-(".
>> 
>
> Well, there's bash,

Wrong.  Any POSIX-compatible shell will work.  In fact, ksh is
preferred over bash.  It runs the FFmpeg configure script twice as
fast.

> a "configure" script with similar interface (and config.err),

Shouldn't you mention that we use make too?

> .h dependencies created in a .depend file (instead of a .deps dir),

Are you arguing that our system is similar to or different from automake?

> files with strings replaced like @PREFIX@,

Wrong again.  We have none of that.

> the need for a gcc toolchain, etc.

The build system doesn't require gcc.  Only some inline assembler
requires gcc.

> It is certainly simpler but it has an overall similar structure.

That's impossible since auto* has no structure whatsoever.

> P.S.  For me a good test for autotool issues is building out-of-source. 
>   I usually do:
>
> $ mkdir build-os-arch && cd build-os-arch && ../bootstrap (or whatever)
>
> If the project does not build well out of source, it is already a good 
> sign the coder does not really know autotools.  Another bad sign is if 
> the project does not build properly with make -j2 or similar.

Building outside the source tree and parallel make both work fine in
FFmpeg.

What was your point again?

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list