Opened 17 years ago
Closed 6 years ago
#189 closed task (fixed)
Generate minimal distribution of Boost libraries
Reported by: | mloskot | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 3.4.0 |
Component: | Thirdparty Components | Version: | 3.2.0 |
Severity: | 3 | Keywords: | boost bcp |
Cc: | External ID: |
Description
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 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
Change History (8)
comment:1 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 17 years ago
Keywords: | bcp added |
---|
comment:3 by , 17 years ago
Milestone: | 3.3.0 → 3.3.1 |
---|
comment:4 by , 17 years ago
I've updated boost.vcproj to limit building of Boost libraries to only those used in FDO (r3891)
comment:5 by , 17 years ago
I've forgot to add. The r3891 submission decreases number of Boost binaries build with build_thirdparty script to required minimum as well as speeds upcompilation process. Thus, we got ~25 MB of Boost binaries instead of ~330 MB.
Next step is use bcp to decrease storage footprint of the Boost distribution included in FDO tree.
comment:7 by , 16 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:8 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed by virtue of FDO trunk no longer using boost
Here is simple headers-based analysis of Boost libraries usage in current FDO trunk:
Next, I'm going to prepare (using bcp) minimal distribution of Boost libraries including subset of these headers only.