- Boost - lists.boost.org

SVN commit and inspection checks?
by John Maddock 05 Aug '07

05 Aug '07

Just wondering, but can we set up the SVN commit script to verify the file with our inspect program before a commit is allowed? No doubt folks will be greatly annoyed by this at first, but at least we should gradually get those inspection-failures fixed that way :-) John.

6 5

new proposal: boost-config
by Domenico Andreoli 05 Aug '07

05 Aug '07

Hi, Suppose two systems, a Fedora based on gcc 4.1 and a Debian based on gcc 4.2, both sporting Boost 1.35.0 built with --layout=system, for simplicity. Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen? BTW, the user is a free software developer and his app is going to be ported also to other Microsoft, UNIX and popular embedded operating systems, where Boost has been built mixing --layout=system and --layout=versioned. Now he faces the problem of linking to the Boost library of interest. How he is supposed to solve the problem? This is a new summary of the binary and source portability problems that current build system is inflicting on the Boost libraries. My proposal is: 1) dump the --layout= thing, versioned/decorated sonames are always used 2) provide symlinks like the following, when appropriate: /usr/lib/libboost_date_time-gcc42-1_34_1.so -> libboost_date_time-gcc42-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-d-1_34_1.so -> libboost_date_time-gcc42-d-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-mt-1_34_1.so -> libboost_date_time-gcc42-mt-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-mt-d-1_34_1.so -> libboost_date_time-gcc42-mt-d-1_34_1.so.1.34.1 3) provide also these symlinks, if desired: /usr/lib/libboost_date_time.so -> libboost_date_time-gcc42-1_34_1.so /usr/lib/libboost_date_time-d.so -> libboost_date_time-gcc42-d-1_34_1.so /usr/lib/libboost_date_time-mt.so -> libboost_date_time-gcc42-mt-1_34_1.so /usr/lib/libboost_date_time-mt-d.so -> libboost_date_time-gcc42-mt-d-1_34_1.so 4) add more decorations as required. e.g. Python version to Boost.Python library name. This way multiple Boost.Python libraries, every built with a different Python version, could coexist on the same system. 5) provide a program, say boost-config, that may be invoked to find the right build parameters for a given library, toolset and variant(s). some examples (suppose default compiler is gcc 4.0, the one used to build Boost): $ boost-config --name=DateTime --ldflags -lboost_date_time-gcc40-1_34_1 $ boost-config --name=DateTime --toolset=gcc-4.1 --variant=mt,d --ldflags -lboost_date_time-gcc41-mt-d-1_34_1 $ boost-config --name=Threads --toolset=gcc-4.2 --ldflags -lboost_threads-gcc42-mt-1_34_1 $ boost-config --name=DateTime --toolset=gcc-4.2 --variant=python-2.5 --ldflags Error: unknown variant python-2.5 for the given library $ boost-config --name=Python --variant=python-2.4 --ldflags -lboost_python-gcc40-python24-1_34_1 $ boost-config --name=Python --toolset=gcc-4.2 --variant=python --cxxflags -I/usr/include/python if toolset is omitted, the default system compiler is used, if any (e.g. cc/c++ under linux), otherwise an error is reported. Point 1) is really optional. In case --layout is kept, the subsequent points would be related only to --layout=versioned and --layout=system should be documented as source of any sort of portability issues. Point 2) is required only on UNIX systems where GNU ld is used, it might have not sense with other linkers. Every linker has its own story. Point 3) is applicable only where 2) is and would be handy only when source portability is not an issue, to the user discretion. Big warning about source portability should be placed nearby its documentation. Point 4) would allow packaging Boost.Python on distributions in which multiple versions of Python may be available. Point 5) is the way to the complete source portability, at least across sane systems (read, probably not Windows/MSVC). Note that if Boost is built using a compiler different from the one asked to boost-config, the linker will complain about the inexistent library. It would be easy to make boost-config extract allowed parameter combinations from an XML file built by Boost.Build at build time. That's all, good night. Domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

5 9

1.34.1 PDF docs
by Vladimir Prus 05 Aug '07

05 Aug '07

Over at https://sourceforge.net/project/showfiles.php?group_id=7586&package_id=1597… I see PDF docs for 1.33.1, but not for 1.34.*? Is this omission intentional? - Volodya

1 0

interest in a stats library?
by Chris Fairles 04 Aug '07

04 Aug '07

I'm wondering if anyone has started a statistical analysis library at all? Something I might be interesting in starting if not. It could include features such as: sample mean, alpha-trimmed mean, weighted-mean, geometric-mean, harmonic-mean, mode, median, midrange. mean deviation, sample std deviation, RMS, sample range, interquartile range higher order sample moments maximum likelihood estimators (and other estimators for various distributions), confidence intervals, hypothesis testing linear regression, ANOVA even Any interested in such a lib? (i think i saw a probability lib somewhere, it could build on that as well). Chris

4 4

Testing tools location.
by Rene Rivera 04 Aug '07

04 Aug '07

NOTE: This is not question about the whole testing & release management stuff on that /other/ thread. Since I'm going to be mucking about with Buildbot this weekend I'm wondering about where to put things in the SVN repo. Instead of continuing to shove stuff into the boost-root/tools tree, I'd rather move some of the testing infrastructure tools onto their own tree as we did with the beta web site. The goal, as with the web site, is to make it easier to develop without getting in the way of the release content. In particular because like the web site, testing doesn't follow the same release schedule as the libraries. The obvious location I have in mind is a top level testing dir, with subdirs as needed: svn/testing svn/testing/buildbot svn/testing/reports ... Thoughts? ...I'll assume this is OK after a short time. And move stuff around/back if people object. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 3

[x-files] the code's out there...
by Tobias Schwinger 03 Aug '07

03 Aug '07

Dear fellow Boosters, There is lots of useful, Boost-worthy utility code out there: Implementation details of existing / upcoming / (maybe even) proposed and rejected libraries that could stand alone, code on private hard disks never brought up for review, additions to existing libraries, etc. Fact is, that for small submissions the administrative overhead of (even) a formal (fast-track) review can be too high for developers' decency. Just imagine someone allocating five fast-track slots at once just for factoring out some unrelated bits of code from an existing library. So, why not group a bunch of unrelated utilities into a set of "Boost X-Files" and have them reviewed as a single library? It's completely non-intrusive to the review process and could seriously increase its efficiency. Like the idea? As a start, I stuffed my (tested and documented) "Boost candidate bits and pieces" into a common directory in the vault: http://tinyurl.com/35vlvb Feedback and more X-files welcome, of course. Regards, Tobias

3 6

Improving --layout=system
by Caleb Epstein 03 Aug '07

03 Aug '07

I sent this to the boost-build list, but I think it should have been CC'ed to this list as well. I'd like to commit this change to the SVN trunk if there are no objections. I think its a big win for anyone who uses --layout=system. This is the way BBv1 (correctly IMHO) handled --layout=system. ---------- Forwarded message ---------- From: Caleb Epstein <caleb.epstein(a)gmail.com> Date: Aug 2, 2007 2:23 PM Subject: Improving --layout=system To: "Boost.Build developer's and user's list" <boost-build(a)lists.boost.org> On systems that support shared library version numbers, I believe that these should be used even when building with --layout=system. At present, when you build Boost with --layout=system, you end up with libraries called libboost_xyz-mt.so that have this same value set at their ELF SONAME (this is the shared library version number embedded into the library itself). The problem with these libraries is that you can never have multiple versions of them installed side-by-side in the same place. Go too far down this road and you end up with Windows-style 'DLL hell'. If instead the BOOST_VERSION is appended to the target name as it is with --layout=versioned, you end up with SONAME'd libraries that can live side-by-side with earlier/later versions of Boost. For example, by adding the version number to the libraries, you end up with a lib directory that looks like: lrwxrwxrwx 1 cepstein 33 Aug 2 13:44 libboost_date_time-mt-d.so -> libboost_date_time-mt-d.so.1.35.0 -rwxrwxr-x 1 cepstein 388K Aug 2 13:44 libboost_date_time-mt-d.so.1.35.0 lrwxrwxrwx 1 cepstein 31 Aug 2 13:44 libboost_date_time-mt.so -> libboost_date_time-mt.so.1.35.0 -rwxrwxr-x 1 cepstein 52K Aug 2 13:44 libboost_date_time-mt.so.1.35.0 ... Now when you link applications using -lboost_date_time-mt, the linker records the dependency on the library's SONAME, which is libboost_date_time_mt.so.1.35.0. No other name will satisfy this runtime dependency. As a result, you can install the (hypothetical) Boost 1.36.0libs into the same directory and old applications will continue to pick up the *.so.1.35.0 libs correctly, while new applications built when the symlink points to the new library versions will pick up *.so.1.36.0. This is how Boost.Build v1 handled --layout=system and I believe this is the most correct and desirable behavior for platforms that support versioned shared libraries. Attached is my simple patch against the latest SVN trunk to make this work. -- Caleb Epstein

1 0

SVN problem with commit
by Paul A Bristow 03 Aug '07

03 Aug '07

I am unable to commit any file or files to Boost-sandbox\math_toolkit with the following message. (I have tried an update and it does it OK). Modified: I:\Boost-sandbox\math_toolkit\boost\math\policy\policy.hpp Sending content: I:\Boost-sandbox\math_toolkit\boost\math\policy\policy.hpp Error: Commit failed (details follow): Error: MERGE request failed on '/svn/boost/sandbox/math_toolkit/boost/math/policy' Error: 'pre-commit' hook failed with error output: (nothing follows error output:) Update to I:\Boost-sandbox\math_toolkit\boost\math\policy\error_handling.hpp Completed: At revision: 38396 Modified: I:\Boost-sandbox\math_toolkit\boost\math\policy\error_handling.hpp Sending content: I:\Boost-sandbox\math_toolkit\boost\math\policy\error_handling.hpp Error: Commit failed (details follow): Error: Cannot write to the prototype revision file of transaction '38396-1' because a previous representation is currently being written by this process Any suggestions? Patience and re-try? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

5 9

Missed 1.34.1 announcement site?
by Daryle Walker 03 Aug '07

03 Aug '07

Our SourceForge project page at <http://sourceforge.net/projects/boost/> doesn't (yet) have an announcement about 1.34.1. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[multi_index][ann][rfc] Preview of Boost.MultiIndex 1.35 release
by Joaquín Mª López Muñoz 03 Aug '07

03 Aug '07

Hello, I've uploaded a preview version of Boost.MultiIndex as planned for shipping with Boost 1.35 --I don't think there'll be time to include more major features. Download at the Vault: http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… (file multi_index.zip) You can try the preview with Boost 1.34.x; if you want to test the newly added interoperability with Boost.Interprocess, you'll have to use a snapshot of Boost CVS, where this library currently lies. The new important features: * New global_fun predefined key extractor. * Added iterator_to facility. * Included support for non-standard allocators such as those of Boost.Interprocess, which makes multi_index_containers placeable in shared memory. Don't miss example #12 at the examples section, which fully exercises this new capacity. * New versions of modify and modify_key with rollback, as described in the tutorial. * Indices provide the new cbegin, cend and, when applicable, crbegin and crend member functions, in accordance with the latest drafts of the next revision of the C++ standard. A longer list of changes can be consulted at the release notes page. I'd be extremely grateful if you can try this preview version and report any problems you find. As we're still in time to discuss the new features, do not hesitate to comment on these and bring forward your proposals for improvement. Thank you very much for your interest in Boost.MultiIndex, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4