personnally I use 1.49 on both my mac and my @pasteur.fr machine.
Le 07/08/12 19:21, Daniel Russel a écrit : > 1.33 is 6 years old (what we support) > 1.36 is 4 years old (we often check for versions older than this to > work around things) > 1.40 is 3 years old (current centos) > 1.46 is 1.5 years old (boost filesystem v3 introduced) > 1.51 is in beta now > > On Tue, Aug 7, 2012 at 10:05 AM, Barak Raveh <barak@salilab.org > mailto:barak@salilab.org> wrote: > > I am really ignorant about boost versions and file systems, just > curious - how old are the various versions? What happens if we try > to apply the X=2 years or so policy? > > > > On Aug 7, 2012, at 9:58 AM, Daniel Russel <drussel@gmail.com > mailto:drussel@gmail.com> wrote: > > > Boost has dropped support for filesystem v2 as of 1.49, so > directories.cpp needs to be patched. It is already a mess with > trying to support the various permutations of things (VC or not, > boost < 1.35, boost < 1.36, and now boost filesystem v2 vs v3, no > boost file system) so it would be really nice to simplify it. Some > options are: > > 1) only support boost.filesystem v3 (with windows) or no > boost.filesystem: the motivation being that this is the way > forward and there is no reason on windows not to be using the > latest boost since there is no pre-installed version. The down > side is that CentOS 6 doesn't have v3. But there is all the > backwards compatibility there. > > 2) drop support for boost < 1.36 and not having > boost.filesystem, so only support fileysystem v2 and v3 (and > perhaps only v3 with windows). I don't see any reason why someone > would have some boost libraries and not others, and if you don't > have any, an awful lot of IMP goes away. And when queried before, > no one actually had a useful machine running such an old boost > version (I'll post on the user list to get a, perhaps, wider sample). > > 3) drop support for boost filesystem. We currently have > workarounds that work on windows, mac and unix/linux systems, so > this isn't much work. But it makes it hard to add extra > functionality as we move forward. > > > > Thoughts? I'm for 2. > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org mailto:IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org mailto:IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev