[FFmpeg-devel] [PATCH] Windows documentation

[Diego Biurrun]

On Tue, Oct 23, 2007 at 01:21:10AM -0300, Ramiro Polla wrote:
>
> The Windows Documentation is awfully outdated. Even though I host the Win32 
> wiki, I think the FFmpeg docs should have simpler and not-so-detailed 
> instructions for the same purpose.
>
> Attached patch pretty much sums up the wiki without all the dumb details 
> that normal Windows users are likely to not know about.

Looks excellent, please commit, some comments below.

> --- doc/general.texi	(revision 10843)
> +++ doc/general.texi	(working copy)
> @@ -341,119 +341,66 @@
>  
> + at itemize
>  
> +Notes:

I'd put the 'Notes:' before the @itemize.

> + at item Use at least bash 3.1. Older versions are known to be failing on the
> +configure script.

known to fail

> + at item In order to compile VHooks, you must have a POSIX compliant libdl in your
> +MinGW system. Get dlfcn-win32 from @url{http://code.google.com/p/dlfcn-win32}.

vhooks, POSIX-compliant

> + at item The target @code{make wininstaller} can be used to create a
>  Nullsoft based Windows installer for FFmpeg and FFplay. @file{SDL.dll}

Nullsoft-based

>  @item By using @code{./configure --enable-shared} when configuring FFmpeg,
> -you can build @file{avcodec.dll} and @file{avformat.dll}. With
> - at code{make install} you install the FFmpeg DLLs and the associated
> -headers in @file{Program Files/FFmpeg}.
> +you can build libavutil, libavcodec and libavformat as @file{dll}s.

DLLs

> -FFmpeg will not compile under Visual C++ -- and it has too many
> -dependencies on the GCC compiler to make a port viable. However,
> -if you want to use the FFmpeg libraries in your own applications,
> -you can still compile those applications using Visual C++. An
> -important restriction to this is that you have to use the
> -dynamically linked versions of the FFmpeg libraries (i.e. the
> -DLLs), and you have to make sure that Visual-C++-compatible
> -import libraries are created during the FFmpeg build process.
> +FFmpeg will not compile under MSVC++ -- and it has too many dependencies on the
> +GCC compiler to make a port viable.

The official party line is that this is due to MSVC++ not being
compliant to the C standard, see the FAQ.

Also, please try to keep lines below 80 characters, same below and
above.

> +MinGW. However, you will not be able to debug inside the libav* libraries, since
> +MSVC++ doesn't recognize the debug symbols generated by GCC. We strongly

does not

> + at item Build your application, and all should work.

Build your application, everything should work.

> +Alternatively, you may start the @file{Visual Studio 2005 Command Prompt}, and
> +from there run @file{c:\msys\1.0\msys.bat}.

run @file{c:\msys\1.0\msys.bat} from there.

> +To use those files with MSVC++, do the same as you would do with
> +the static libraries, described above.

as described above

> +statically linked into the @file{dll}s. The @file{bin} directory contains a

DLLs

> +bunch of @file{dll} files, but the ones that are actually used to run your

DLL

> +application are the ones with major version number in their filenames (i.e.

with a major version number

Diego