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

Gonzalo Garramuño ggarra
Wed Mar 5 17:26:26 CET 2008

M?ns Rullg?rd wrote:
> Wrong.  Any POSIX-compatible shell will work.  

Fine.  If you want to be strict about it, sure.  Point being that, just
like autotools, you also place a requirement on a specific
command-shell.  Does that work for you?

>> a "configure" script with similar interface (and config.err),
> Shouldn't you mention that we use make too?

Sure, if you want.  That's also part of the gcc toolchain and a requirement.

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

Similar.  You are keeping dependencies on disk and relying on, most
likely, gcc -MM or similar  (see a problem below with that).

>> files with strings replaced like @PREFIX@,
> Wrong again.  We have none of that.

True.  You have a bash script that spits out variables with cat <<EOF.

>> the need for a gcc toolchain, etc.
> The build system doesn't require gcc.  Only some inline assembler
> requires gcc.

Not true, the make system currently imposes the compiler
to be compatible with gcc's flags (-MM for example needs to spit
dependencies, etc. ) besides any assembler.

Even if I add a proper stdint.h to MSVC for example, there's no way that 
the current make system will actually work for it, as -MM does not spit 
dependencies under that compiler.

Any way you look at it, the ffmpeg system is very similar to autotools. 
  It is just simpler and customized to ffmpeg.  But fundamentally, it is 

A make system that I would call really different would be something like 
scons or bjam (that does not even use make at all) or something like 
rake (which uses meta-programming to define rules).

> What was your point again?

The *original* point of the thread was about .lib files without
versioning and how that prevents easily
installing/shipping/deploying/supporting ffmpeg and future versions.  So
far, you have not explained to me how the current approach is superior.

Parallel building works in ffmpeg (never said otherwise).
But out of source for multiple platforms simply does not work as
reliably as autotools.

I'll post the issues with out-of-source I see in a separate thread.


Gonzalo Garramu?o
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
Xubuntu Gutsy

More information about the ffmpeg-devel mailing list