Re: [Boost-users] [general] boost 1.35.0 library naming and bjam arguments priorities

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-07-15 03:57:28

> John Femiani wrote:
> > Is this issue specific to mingw, or does it apply to 
> cygwin's gcc as 
> > well (or Interix, or whatever, if they are supported by boost?)
> >
> >   
> It is specific to mingw. cygwin uses the unix convention of 
> .a and .so files.

Really? I'll have to try that -- the redhat website seems to say that
-lxyz would never find a '.so' file.
http://tinyurl.com/6bygtj

> > Would it be acceptable if there were a different target or 
> option to 
> > generate .lib files with toolset=gcc, in addition to 
> generating .dll.a?
> >   
> You mean something similar to --layout=system ?
> What would you suggest?
> 
> The whole point is that boost currently has naming that is 
> aimed at the platform and not primarily on the used toolset. 
> I am not sure this really should be changed, but ...
> 

Since when? It used to be that mingw produced .a files, and that makes
perfect sense to me. Do you try to produce object files with '.obj' or
'.o' extensions? As I see it, .exe and .dll files don't need to be fed
back into the toolchain again. A .lib or .a file is different, it is
only partialy built. It needs to be fead _back_ into the toolchain in
order to produce a .dll or .exe at some point. I buy the "platform"
argument for .dll and .exe, but I think that the intermediate files like
static libs and objects should use the toolchains convention, or at
LEAST extensions that work with the toolchain in a way that does not
require detective work.

That, by the way, seems to be the convention used by mingw itself. They
use .dll and .exe, but stick with .o and .a for objects and static libs.

> > Since xyz.lib has less priority than libxyz.a, adding a .lib won't 
> > cause
> > g++ to pick the wrong library with -lxyz. One would still need a 
> > g++ .dll.a
> > version or else g++ would try to choose the static library 
> even when 
> > one wanted dyamic linking.
> >   
> If I understand you well you mean both libs should be 
> generated? 

It could go either way, but I think the default should be to produce
dll.a only. An option to produce .lib in addition or instead could
satisfy people who want to compile with gcc but link their final app
with msvc. Really, you need .lib files (as opposed to .a) if you are
mixing compilers, or rather mixing toolchains. That is useful but should
not be the default behavior, it should require another explicit option.

> Hmm, smells like bloat, doesn't it?

I am suggesting "bloat" that the user must specifically ask for (so I
wouldn't call it bloat). I suppose hard links could be used on newer
windows if you want to save on disk space?

-- John