boost versions and directories.cpp
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.
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
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 >
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
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
Daniel, if it makes it easier for maintenance, then by the X=2-3 years policy we can even drop anything before Boost 1.40 (only if supporting 1.36 is a lot of effort - of course it's always fine to keep it if it's not too much hassle)
On Tue, Aug 7, 2012 at 11:13 AM, Daniel Russel drussel@gmail.com wrote:
> 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 listIMP-dev@salilab.orghttps://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 > >
On 8/7/12 10:05 AM, Barak Raveh 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?
RHEL 5 (as we discussed, the latest enterprise RH until 1.05 years ago) ships with Boost 1.33. But Boost 1.41 is available in EPEL for RHEL 5, so anybody that still wants to use RHEL 5 could quite easily install Boost 1.41. So requiring Boost 1.36 or later (Daniel's option 2) sounds reasonable to me.
Ben
participants (5)
-
Barak Raveh -
Barak Raveh -
Ben Webb -
Daniel Russel -
Yannick Spill