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

[Gonzalo Garramuño]

M?ns Rullg?rd wrote:
>>>
>> More likely, it has everything you need :).
> 
> The difference being?
> 

You != me.

> 
> The git repo is updated immediately on every svn commit.
> 

Cool.  So I'll assume your answer to the other thread about a fix being 
put in place was sarcasm with bad net etiquette.

Please, Mans, while I do sometimes find your dry humor funny, while you 
are in the middle of a technical discussion with me, can I bother you to 
please make sure you mark your humor as such.  :) is just two 
keystrokes.  You just made me spend some minutes seeking for that fix in 
git.

> 
> I'd say an explicit dependency check is the more reliable of those
> options.
> 

In principle, yes.  In practice for this case, no, I'm afraid I don't 
agree there.

Consider doing that in this case means writing a parser for the output 
format of a utility that is not really shipping with the os or target 
(neither mingw nor windows), is not compatible with utilities in unix 
land, whose source I may not even have (as depends.exe) and which scans 
a COFF format of microsoft that is, afaik, proprietary (albeit documented).

vs...

A Makefile whose source code I can see, uses only elements that ship 
with mingw/msys and will compile myself with a known dependency and that 
just requires a change that, at least to me, seems rather simple.

> 
> If distributing the right version is causing you so much worry, why
> don't you link statically instead?  That removes the entire problem
> of versioning, and gives you better performance at no extra cost.
> 

AFAIK, and correct me if I am wrong, that makes the code not be able to 
be LGPL (which is the ffmpeg licensing I've chosen for this project).

> 
> You'd still have to keep old versions of the header files around.  It
> really would be much simpler for you to install each ffmpeg version in
> a separate directory (configure --prefix).
> 

That is a better argument.  Due to strict enforcing you do of LGPL, I 
will have to keep the ffmpeg source distro in my web server, so I don't 
really need to keep sources on my disk unless I do have a bug to fix.
If I had to do it often, I'd keep libs disted as unix land in a single 
dir and rely on using --incpath for headers with versioning, not 
--prefix. This makes it easier for me to automate any changes later on 
across platforms, as windows and unix file structures would look identical.



>> I think this is something imaginary.  I seriously doubt anyone can
>> expect you to actually fix problems with the OS or file system.
> 
> Users come to us demanding exactly that all the time.  Search the
> archives for stdint.h and see for yourself.
> 

Don't compare apples and oranges.  I'm not planning to open that door. 
stdint.h is a C99 requirement (which is clearly specified in the ffmpeg 
page).  Use of LIB files is not.  It is mainly a windows requirement, 
which you gently provide some support for in the makefile (appreciated).

If you follow microsofts approach to their own libraries, you find their 
runtimes versioned with both the .lib and .dll with the same name (ie. 
msvcr70.lib/msvcr70.dll), or no version name at all (ie. kernel.dll/lib 
leading indeed to potential DLL hell).

Under MingW, lib files are optional (mingw gcc can link to DLLs directly 
-- but linking will probably be faster with the lib files around).  As 
MinGW may be used for either coding directly to windows or as bridge to 
GNU elements, you may see two camps there either traditionally sticking 
to what's standard under windows/microsoft and those sticking a more 
Unix (really, autotools) convention with MSYS.
ffmpeg currently installs LIB files (like microsoft needs) but I don't 
think it follows any of those two conventions.  It kind of leans more 
towards behaving like autotools, but also not quite.

 >
 > You want to ship versioned dlls.  We build version dlls.  Where is the
 > problem?
 >

No.  I want versioned DLLs and corresponding versioned LIBs (ie. 
something akin to what microsoft does with their msvcr71.lib and 
msvcr71.dll).
I don't care either way for their unversioned ones (if you want to 
install them, great too).

You build both files versioned, but install only unversioned LIBs.

Anyway, with all this discussion, you made me realize that the current 
install procedure under mingw is also perhaps kind of backwards. 
There's only the need to install a single versioned DLL (not multiple 
ones as is now as neither the compiler nor linker nor runtime uses the 
others) and there's the (at least my) need to install versioned LIBs 
(which linkers and makefiles can indeed take advantage of).

I think the best procedure for me to avoid what seems like a 
confrontation with you for a simple thing (and not have a nightmare in 
maintainance with a complex work-around) is to just create my own 
"Makefile.install" with an install rule according to my needs inside my 
ffmpeg trunk.  After all, the build part (which is the hard part of the 
makefile) is done versioned.  It's only the install that throws that 
info away the part I don't agree with.


-- 
Gonzalo Garramu?o
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy