[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