Re: [jamboost] "Installation" of boost

From: Rene Rivera (grafik666_at_[hidden])
Date: 2001-12-31 10:31:52

On 2001-12-20 at 05:52 PM, dmoore_at_[hidden] (dmoore99atwork) wrote:

>I posted the following question on the main Boost list, and David 
>Abrahams suggested that I follow up here...
>
>
>>> 1. Is there the equivalent of "make install" which would gather all
>>> of the .lib and .dll files from the deeply nested directories and
>>> deliver them somewhere like BOOST_ROOT\lib? For example, my RegEx
>>> binary is in boost\libs\thread\build\bin\libboost_regex.lib\msvc-
>>> stlport\release\runtime-link-dynamic\stlport-iostream-off\stlport-
>> version-4.0\libboost_regex.lib
>
>>Not yet. We're thinking about it, but nobody has yet figured out what
>>installation of boost should really mean, especially on Win32 
>>platforms. If
>>you have any well-formed ideas, pleas bring them up on
>>jamboost_at_y...
>
>I'm sure my ideas are not well formed (ha), but here is what I am 
>looking for/thinking, for the compiled libraries (i.e. RegEx, Python, 
>and Thread).
>
>Win32 programming can get you into all kinds of nightmares with the C 
>and C++ runtime libraries (Debug/Retail, Single/Multithreaded, 
>Statically or Dynamically Loaded). With these permuatations, it's 
>hard to please everybody. 
>
>If you go with one "lib" directory containing either the complete 
>static library or the .dll stub library, the "complete" solution 
>probably means creating libboost_threadXYZ.lib and 
>libbost_threadXYZ.dll where XYZ is a code for the permuatation - i.e. 
>DMS meaning debug multithreaded static... This is ugly, but has been 
>used to effect by Mircosoft and IBM over the years on Windows and 
>OS/2.
>
>If the BOOST_ROOT\lib directory had subdirectories for the 
>permutations, then each VC++ project could add the particular 
>subdirectory to its library search path, but you would still have 
>either a name collision or PATH problem for the binary .dll files...
>
>In actual practice, I don't move around much. I tend to use the 
>dynamically linked multithreaded libs. Others would of course tend 
>towards different combinations. What would suit me is another 
>command line argument which would deposit the libraries which were 
>*just* built for the particular toolset into an "installation" 
>directory. I would have my one combination in BOOST_ROOT\lib, and I 
>could easily "swap out" for another combination en masse by running a 
>jam command...

I think what your are talking about is not doing an installation. What you
seem to be referring to is creating a stage directory. Collecting files in a
stage directory in preparation for an installation is a common practice for
large projects.

It makes sense to me to separate your second suggestion into a separate target
specifically for creating a stage directory and basing the install on it. That
way developers can build the stage, do some testing to make sure it works as a
whole, and then do an install, or even a package.

How about adding a "stage" rule like so:

stage <name> : <sources...> [ : <requirements> [ : <defaults...> ] ] ;

The sources could contain references to other targets as usual, so <lib>*,
<exe>*, <dll>*, and also <stage>* would work.

For requirements we would need to be able to specify the directory of the
stage, and to specify how to rename files. So possibly: <dirname>*, and
<pattern>*.

Specifying a renaming pattern is the most complicated. We would want to
support both simple renaming and abbreviated renaming. For simple renaming
either doing something like "<pattern>basename+variant+extension" would be
minimal, also possible would be to have some sort of regex pattern ala Perl
search&replace patterns. For the abbreviated renaming we would need some way
to specify how to map the various variant specs to single(or double) letter
equivalents. We could use the same syntax for the pattern and "turn on" the
abbreviated renaming with another requirement spec, like
"<abbreviated>on|off".

Using this might look like so:

project-root ;
subinclude sub/test ;
stage test_stage : <stage>sub/test/my_test_stage : <dirname>stage : release ;

subproject sub/test ;
lib my_lib : ... ;
exe test_app : ... ;
dll my_dll : ... ;
stage my_test_stage
: <lib>my_lib <exe>test_app <dll>my_dll
: <dirname>staging <pattern>basename+variant+extension <abbreviated>on
: release debug ;

Having that it makes it that much easier to then define an install based on
the stage as "install <stage>test_stage ;". Also packaging could be specified
in a similar way: "package distribution : <stage>test_stage README.txt
INSTALL.txt ;".

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]