
I was wondering if there is a specific reason still that when using mingw to build the boost libraries it defaults to using the .lib extension? I was only able to find the following post: http://article.gmane.org/gmane.comp.lib.boost.devel/79594 Which is where David Abrahams states that file extensions are based on platform and not based on toolset. I've been using mingw lately, and at least current versions are able to find a library with a .lib extension without any problem. However, visual studio can not use that file as a library, and mingw will look for a .a first. What I'm thinking is that at least for the undecorated versions of the libraries (boost_python.lib) it should use the common convention for the compiler, that way you could have both in the same directory, and have the compiler pick the right one. I realize I can force this with a '-sSUFLIB=.a', I was just wondering if there was a reason the extension is based on platform, and not on TOOLS. John =:->

John Arbash Meinel wrote:
Which is where David Abrahams states that file extensions are based on platform and not based on toolset.
For what its worth, this is probably not right. Extensions reflect file format, which is dependent on compiler, not operating system. If Boost.Build were ported to a Windows compiler that didnt use .lib at all, it would obviously be wrong for bjam to use that extension. As a philosophical matter, the closer that MinGW is treated to other GCC targets, the better (in the long run). It is my hope that there will be one day when we won't have a "MinGW," but instead just a GCC for Windows. Aaron W. LaFramboise
participants (2)
-
Aaron W. LaFramboise
-
John Arbash Meinel