[fdo-trac] #189: Generate minimal distribution of Boost libraries

[FDO]

#189: Generate minimal distribution of Boost libraries
-------------------------------------+--------------------------------------
   Reporter:  mloskot                |       Owner:  gregboone
       Type:  task                   |      Status:  new      
   Priority:  major                  |   Milestone:  3.3.0    
  Component:  Thirdparty Components  |     Version:  3.2.0    
   Severity:  3                      |    Keywords:  boost    
External_id:                         |  
-------------------------------------+--------------------------------------
 This task is about extracting minimal set of Boost libraries used in FDO,
 so the footpring is minimized.

 Here is longer discussion that took place during the
 [wiki:PscMeeting20071205 FDO PSC Meeting] on 12-5-2007:

 {{{
 [19:38]  <gregboone> Lets move on to Boost
 [19:38]  <gregboone> The latest version has been submitted, but the
 footprint is large
 [19:38]  <gregboone> Ideas?
 [19:39]  <mloskot> 1. use system/user's version of boost
 [19:39]  <mloskot> 2. use bcp utility to generate subset of boost
 libraries
 [19:39]  <mloskot> 3. Windows users can use available binaries
 [19:39]  <mloskot> 4. Linux users have binaries too as packages
 [19:40]  <gregboone> The general rule for FDO Thirdparty is to ship all
 dependant library source code where possible
 [19:40]  <mloskot> Option 3 means boost lives in FDO tree
 [19:40]  <mloskot> ** Option 2
 [19:40]  <mloskot> 1, 3, 4 - external libs
 [19:40]  <gregboone> We can prune the boost tree to just include datetime
 and thread source
 [19:41]  <gregboone> We could always add new boost components as required
 [19:42]  <gregboone> I think that options 1,3, 4 are harder to maintain
 [19:42]  <mloskot> Honestly, using boost is very simple the only need is
 to specify min required version
 [19:43]  <mloskot> so, I can't see what's harder in 1,3,4
 [19:43]  <gregboone> I do not doubt that, but I am concerned that changing
 the process may make the user experience more difficult
 [19:43]  <mloskot> agreed
 [19:44]  <gregboone> Can we take option 2 and make a more flexible
 solution a longer term goal?
 [19:45]  <mloskot> gregboone:  yes
 [19:45]  <mloskot> First, we need to identify what libraries we use
 [19:45]  <gregboone> thread and datetime is it
 [19:45]  <gregboone> no others
 [19:45]  <mloskot> Second, we run bcp
 (http://www.boost.org/tools/bcp/bcp.html) to extract all of them with
 dependencies
 [19:45]  <mloskot> gregboone:  ok, so these are two binary libraries
 [19:46]  <mloskot> but there is number of headers-only libs used
 [19:46]  <gregboone> I see
 [19:46]  <mloskot> at least I use them as I love them :-)
 [19:46]  <mloskot> in PostGIS provider I mean
 [19:46]  <gregboone> Maybe an offline discussion on fdo-internals will
 clear up what is required
 [19:46]  <mloskot> gregboone:  I can volunteer to try to do it
 [19:46]  <mloskot> to generated minimal boost package for FDO
 [19:47]  <gregboone> If you could, that would be great
 [19:47]  <mloskot> gregboone:  let me to grep through FDO sources and
 identify libraries and extract them
 [19:47]  <mloskot> Then, I will post to the fdo-internals about results
 [19:47]  <gregboone> Agreed
 }}}

-- 
Ticket URL: <http://trac.osgeo.org/fdo/ticket/189>
FDO <http://fdo.osgeo.org/>
Feature Data Objects