Re: [Boost-users] Mingw: build, install, .LIB files and boost-config?

Subject: Re: [Boost-users] Mingw: build, install, .LIB files and boost-config?
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-02-01 02:40:52

John Pye wrote:

>> Please use SVN HEAD (or 1.42 beta)
>>   
> 
> So I understand that the .a suffix will be correctly implemented for
> Cygwin and MinGW/MSYS for 1.42.0?

The .a suffix will be used for <toolset>gcc <target-os>windows, which 
corresponds to mingw. For cygwin, the current SVN HEAD still uses
.lib extension.
 
> For earlier releases, it's OK to just rename the .LIB files?

Yes.

>>> Finally, there was a bit of discussion on the mailing list about a year
>>> ago about providing a "boost-config" script. With the ever-changing
>>> naming conventions for Boost libs, and the possible presence of static
>>> libraries, shared libraries, -mt, -d, and other file suffixes, such a
>>> script would be INVALUABLE for people looking to access pre-built Boost
>>> binaries for their projects. It would be an almost trivial task to
>>> implement such a script -- has there been any progress on this anywhere?
>>>     
>>
>> I am afraid nobody has ever provided a *specification* for such a script.
>> Presumably, because it's less trivial than originally though. Can you provide
>> a spec?
>>   
> 
> There are countless examples of these scripts, but there's not a
> universal standard for them, nor does there need to be. The key thing is
> that there should be a clear "--help" output from the script that shows
> what possible information can be retrieved. Typical usage and outputs
> 
> $ boost-config --cppflags
> -I/opt/boost/include
> 
> In the case of Boost, there are actually many libraries, rather than
> just one, so the usage of "--libs" would perhaps have to be something like
> 
> $ boost-config --libs=serialization,graph
> -L/opt/boost/lib -lboost_serialization-mt -lboost_graph-mt
> 
> The extra library suffixes etc are things that vary from build to build
> and machine to machine, so the script saves everyone a lot of messing
> around by returning those things according to the local install.
> 
> The above pretty much summarises the basic functionality. The same input
> on a different system could result in different output, eg for static
> libraries Boost:
> 
> $ boost-config --libs=serialization,graph
> /opt/boost/lib/libboost_serialization-mt.a
> /opt/boost/lib/libboost_serialization-mt.a

The question is why is this any better than saying 'thou shalt link to -lboost_serialization'?
Boost 1.41 uses system naming by default on Unix, and earlier versions of Boost will not
have 'boost-config' anyway.

> One might thing about some additional flags that switch to linking
> against 'debug' builds of the libraries, instead of the default release
> versions.
> 
> Once the script is written, it's very simple to build a cross-platform
> makefile to link against Boost, for example
> 
> CPPFLAGS = `boost-config --cppflags
> LINKFLAGS = `boost-config --libs=serialization`
> 
> prog: myprog.cpp
>    $(CXX) $(CPPFLAGS) -o prog myprog.cpp $(LINKFLAGS)
> 
> Something like that, anyway. 

I'm afraid the devil hides in the word "like". Nobody, up to now, was able
to come up with complete specification. And, the only thing that will be
immediately helped by pkg-config/boost-config solution is the filesystem->system
dependency (and that only for static linking)

- Volodya