backwards compatibility
Hello, I realize that Boost doesn't promise ABI compatibility across releases, nor even API compatibility according to the FAQ: How can the Boost libraries be used successfully for important projects? Many of the Boost libraries are actively maintained and improved, so **backward compatibility with prior version isn't always possible**. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the boost repository. (emphasis mine) OK, but *in practice* is there a large amount of work adapting existing client code to a new release? I'm asking in order to gauge whether it is useful for a linux distribution (Debian) to keep multiple versions of Boost available simultaneously; e.g. 1.34.1 and 1.35. Currently Debian provides only the latest version of Boost. Thanks, -Steve
On Sun, 30 Mar 2008 22:37:52 -0500, Steve M. Robbins wrote:
OK, but *in practice* is there a large amount of work adapting existing client code to a new release?
Not if you can recompile the client code. Usually. -- Sohail Somani http://uint32t.blogspot.com
On Mon, Mar 31, 2008 at 12:37 AM, Steve M. Robbins <steve@sumost.ca> wrote:
Hello,
[snip]
(emphasis mine)
OK, but *in practice* is there a large amount of work adapting existing client code to a new release?
I have used the last four releases (1.32, 1.33, 1.34, and now 1.35). And I have found that modifications, most minors, in user code are very common when switching boost version.
I'm asking in order to gauge whether it is useful for a linux distribution (Debian) to keep multiple versions of Boost available simultaneously; e.g. 1.34.1 and 1.35. Currently Debian provides only the latest version of Boost.
I believe that to be a good idea.
Thanks, -Steve
-- Felipe Magno de Almeida
Steve M. Robbins skrev:
Hello,
I realize that Boost doesn't promise ABI compatibility across releases, nor even API compatibility according to the FAQ:
How can the Boost libraries be used successfully for important projects?
Many of the Boost libraries are actively maintained and improved, so **backward compatibility with prior version isn't always possible**. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the boost repository.
(emphasis mine)
OK, but *in practice* is there a large amount of work adapting existing client code tero a new release? I'm asking in order to gauge whether it is useful for a linux distribution (Debian) to keep multiple versions of Boost available simultaneously; e.g. 1.34.1 and 1.35. Currently Debian provides only the latest version of Boost.
I guess it may make sence to keep them around, but that also has it issues - disk space being the most obvious, but binary and interface incompatibillity is likely to be a more serious. I would like to know answers to some questions if anybody have them. Please s/debian/fedora/g or whatever if that helps. How many debian packages actually depend on boost? How many debian packages typicaally need more than a recompile with a new boost version? Are there open source packages or applications debian have to support that uses boost in API or other interfaces? Are there closed source packages or applications debian have to support that uses boost in API or other interfaces? -- Bjørn
Steve M. Robbins wrote:
is useful for a linux distribution (Debian) to keep multiple versions of Boost available simultaneously; e.g. 1.34.1 and 1.35. Currently Debian provides only the latest version of Boost.
Hi Steve, I think Debian (and other distributions) must keep multiple versions available. I have written a couple of GPL programs that currently require 1.34; a Debian user who has compiled these from source will be unhappy if they fail to work when they upgrade their Boost libraries. I could fix my code to work with 1.35, but that will be broken for all those other users who don't have 1.35 available in their distribution. So I'll probably wait until there are Debian and Fedora releases including 1.35 before changing the stable version of my code to use it. An alternative is for me to #if between the different versions. But my life's too short to do that. (And if I did want to do it, how could I install multiple versions on my Debian development machine?) Things are less serious for programs that depend only on header-only libraries, since they will only stop compiling rather than stop running when you upgrade the libraries under their feet. You then have to determine how to name the different Boost versions' header directories and library files. And then how to tell the applications' build systems what names you have chosen. I like pkg-config for this, and did mention it on this list once but without any apparent interest. [Anyterm has been shipping with a version of Boost.Interprocess - at that time called Boost.Shmem - included in its source tree since December 2005 (doubling its size). The next Debian stable release might happen before the end of this year. So that means that it will have taken 3 years for that Boost code to "trickle down" to Linux end-users. Ironically, I plan to deprecate the feature that needed shared memory soon. It's worth noting that Debian, and presumably other distributions, discourage including special versions of libraries within the applications that use them. This is both to reduce the size of the distribution and to avoid the scenario where a library security bug has to be fixed in "hidden" copies of libraries. This problem with a non-Boost library is one of the reasons why Anyterm has never been Debianised.] Cheers, Phil.
On Mon, 31 Mar 2008, Phil Endecott wrote:
Things are less serious for programs that depend only on header-only libraries, since they will only stop compiling rather than stop running when you upgrade the libraries under their feet.
You then have to determine how to name the different Boost versions' header directories and library files. And then how to tell the applications' build systems what names you have chosen. I like pkg-config for this, and did mention it on this list once but without any apparent interest.
By default, boost will install headers to version-dependent directories. Autoconf with boost.m4 (http://repo.or.cz/w/boost.m4.git/) provides a fair deal of flexibility in detecting what versions are installed where (on POSIX platforms). - Daniel
Back in March, Steve M. Robbins wrote to boost@lists.boost.org:
[is it] useful for a linux distribution (Debian) to keep multiple versions of Boost available simultaneously; e.g. 1.34.1 and 1.35. Currently Debian provides only the latest version of Boost.
Hi Steve, I've just had a look at packages.debian.org and as far as I can see there is a package called libboost1.35-dev, which unpacks headers into /usr/include/boost. So although you could have e.g. libboost1.36-dev on the Debian ftp server, it would be impossible to actually install both on the same machine since they would conflict over what to put in /usr/include/boost. Have I understood this correctly? Maybe there is some symlink magic or similar that I have missed. I was about to start converting some of my code to 1.35, but I'm less enthusiastic about that if I have to remove 1.34 and so convert everything in one go. Regards, Phil. p.s. I just clicked on sumost.ca and see that you've been hacking your digital picture frame. Me too. Got Debian running on it yet?
On Mon, Jun 02, 2008 at 12:26:06PM +0100, Phil Endecott wrote:
Back in March, Steve M. Robbins wrote to boost@lists.boost.org:
[is it] useful for a linux distribution (Debian) to keep multiple versions of Boost available simultaneously; e.g. 1.34.1 and 1.35. Currently Debian provides only the latest version of Boost.
Hi Steve,
I've just had a look at packages.debian.org and as far as I can see there is a package called libboost1.35-dev, which unpacks headers into /usr/include/boost. So although you could have e.g. libboost1.36-dev on the Debian ftp server, it would be impossible to actually install both on the same machine since they would conflict over what to put in /usr/include/boost. Have I understood this correctly?
Yes, that is correct. Debian has always supported only a single version of the Boost development package (headers & link libraries) installed at a time. The recent change is that you can now choose one of two versions to install: currently 1.34.1 or 1.35.0. We considered and rejected the idea of having two versions of boost simultaneously installed [1].
I was about to start converting some of my code to 1.35, but I'm less enthusiastic about that if I have to remove 1.34 and so convert everything in one go.
Note that while installing libboost1.35-dev means removing the -dev package of 1.34.1, you can still retain the 1.34.1 libraries and so all existing binaries continue to run normally. You do have to convert in one go all the sourceful projects you work on. This has always been the case with Debian.
Regards, Phil.
p.s. I just clicked on sumost.ca and see that you've been hacking your digital picture frame. Me too. Got Debian running on it yet?
Ha! No, it's not running Debian. However, I emailed the company and they obligingly sent a short document on how to format the RSS feeds. So I now have a couple of channels generated by half-baked python scripts. I should spend some time to cook them up to something more useful. -Steve [1] Thread starting at http://lists.debian.org/debian-devel/2008/04/msg00581.html
participants (6)
-
Bjørn Roald -
dherring＠ll.mit.edu -
Felipe Magno de Almeida -
Phil Endecott -
Sohail Somani -
Steve M. Robbins