Yeah, sorry, I was a bit sloppy. 1.49 is the last supported version, not the first dropped version.

On Aug 7, 2012, at 10:52 AM, Yannick Spill <yannick@salilab.org> wrote:

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> 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> 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
> https://salilab.org/mailman/listinfo/imp-dev

_______________________________________________
IMP-dev mailing list
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

_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev