Boost logo

Boost-Build :

Subject: Re: [Boost-build] Using the install rule with a pre-built library
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2013-03-12 16:28:47


>> I ended up solving my problem by generating the <file> feature using a
>> rule,
>> which borrows the same bjam utilities that are used to generate
>> platform-specific library names. It's not pretty, but it got me there.
> Are you sure your solution works correctly when you attempt to build
> an exe using your target as a source? Does it link to the correct import
> library? I remember it did not when I tried setting the <file> rule
> directly...

   Ok, research results so far...

   Your code, as posted, will do the wrong thing here:

> exe aaa : aaa.cpp MyLib : <link>shared ;

   and will not link the aaa.exe to MyLib's import library

   My solution can be improved a bit like this, to get the same
end-results as before, but with only one target:

> rule wxWidgets-lib ( name : dllFolder : libName : dllName )
> {
> lib $(name) : :
> <link>shared:<file>$(dllFolder)/$(dllName).dll
> <link>shared:<file>$(dllFolder)/$(libName).lib
> <name>$(libName) <search>$(dllFolder) ;
> }
> local dllFolder = "D:/Libraries/WxWidgets/wxWidgets-2.9.4/lib/vc_dll_staticRTL_unicode_PKE_msvc-9.0" ;
> wxWidgets-lib test : $(dllFolder) : wxbase29ud : wxbase294ud_vc_PKE ;

   You can improve the lib/dll prefix/suffix generation code using an
indirect conditional property, of course.

   This gets the following effects:
     - when linking to an exe with <link>static - links with the static
library $(dllFolder)/$(libName).lib.
     - when linking to an exe with <link>shared - links with the static
import libarary $(dllFolder)/$(libName).lib (can easily be modified to
use differently named regular static library and import library, but I
did not require this)
     - when installing an exe with this lib listed as a source using
<link>static - no lib files get installed, independent of any additional
install properties.
     - when installing an exe with this lib listed as a source using
<link>shared, and you tell it <install-dependencies>on - you will get
both the DLL file & the import library installed, but you can control
this by setting <install-type> properties, e.g. list SHARED_LIB and not
LIB - to get only the DLL file installed, and not the import library.

   Still messy, but getting better...

   I believe the whole mess stems from the fact that it is not clear
what it means to 'install a prebuilt library'. :-) If it is a static
library - it might mean 'do nothing' (since the library has supposedly
been used when compiling some product) or it might mean 'copy'. If it is
a shared library - things get even more complicated as it might mean: do
nothing, copy the import library, copy the DLL file or copy both the
import library and the DLL file.

   The current install rule explicitly skips SEARCHED_LIB targets (the
ones you get when you use the lib rule without <file> property and with
either a <name> or <search> property specified) when choosing what
dependencies to select. It does install STATIC_LIB targets though.

   The current Boost Build implementation most likely grew out of the
standard Linux-style file system organization where using
application-private shared libraries stored in some application specific
folder is not the norm and instead, all libraries get installed in some
central location like /usr/local/lib that is always automatically added
to the library search path. Then there is never any need to install
prebuilt libraries as they are always expected to have already been
installed into those folders by their build or installation system.

   It could be redesigned and implemented a bit differently, but someone
would need to step up for that and lead a design discussion, prepare a
working prototype, defend the design, deal with all the 'you idiot! you
broke XYZ!' flames :-P, deal with any backward compatibility issues,
especially those related to building existing Boost libraries, and then
get the whole thing committed... :-)

   For me, the current workaround seems good enough for now. I can
package it up locally as a well commented implementation detail, add a
few tests for it, and it allows me to automatically install prebuilt DLL
targets if I want to and still easily switch between using static or
shared libraries in our products.

   Hope this helps.

   Best regards,
     Jurko Gospodnetić

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at