[Libreoffice] Master Build Status

Joseph Powers jpowers27 at cox.net
Fri Feb 4 21:33:28 PST 2011

I'm able to build master on Mac OS X again. Fredrich's patches caused some fall out.

First off, Fredrich can on line tonight  (my time) and uploaded the last of his patches to upgrade Boost from 1.39.0 to 1.44.0. This my have fixed a few issues. I've done the following fixes:

1. We had about 4 locations where the #include <unordered_map> was guarded by INCLUDED_HASH_MAP. The issue here was that upordered_map already has it's own internal guards and we still use it to guard <hash_map> in about 4 locations. In one case, this was causing a compiler error since the guard got defined when hash_map was included and thus unordered_map wasn't. I fixed all locations just to be safe.

2. We had some forward declare issues with ::std::vector<>. I just did a #include <vector> in the files affected and this fixed the issues. Now that boost has been upgraded, we may be able to remove these #includes. I haven't done any research to see if these can be removed.

3. The upgraded boost referenced /boost/range/algorithm/equal.hxx; however, this wasn't delivered before. I added the lines to the d.lst file to make sure the range/algorithm directory is delivered.

4. The old hash_map code was doing a two pass process for loading the map in several locations. In pass 1, the data was loaded into a temporary <list> in sorted order. In pass 2, they used hash_map.resize( list.size ) pre-allocated enough memory to store the entire list and then the contents of the list where added to the hash_map. The issue here is that unordered_map doesn't have a resize() method so we can no longer do this micro-optimization. In all cases the code was modified to just remove the call to resize(). It would be good to have someone go back and find all the locations where this two step process is used and  see if we can speedup/simplify the code by using a container that will do the sorting for us. The following programs use this pattern (there are more out there):


5. The class T2TypeClassMap was defined twice, once as a unordered_map and once as a hash_map (unodevtools/inc/unodevtools/typemanager.hxx); I changed the 2nd definition to an unordered_map.

Overall, Fredrich didn't break too much and I don't think we need to revert any of his work.

Joe P.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110204/6e35f14c/attachment.html>

More information about the LibreOffice mailing list