Re: [Boost-build] Using the install rule with a pre-built library

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

   Hi.

>> 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ć