Ticket #225 (closed defect: fixed)

Opened 18 months ago

Last modified 13 months ago

Permission to build supercollider with bundled libraries

Reported by: bsjones Owned by: spot
Priority: minor Milestone:
Component: Bundled Library Exception Version:
Keywords: Cc:
Blocked By: Blocking:

Description

Supercollider is an audio synthesis engine and programming language. IT bundles serveral libraries in its source tree, most of which can be avoided at the configure stage. However there are three whihc are problematic:

oscpack - the author of supercollider has made significant changes which have been rejected by oscpack upstream (See attachment). A package for oscpack does exist in CCRMA, but is required by nothing as far as I can see.

boost_lockfree and boost_atomic - both of these packages are being considered upstream by the boost project but have not made it to a release. Boost_lockfree is available in boost trunk but I believe final approval is still pending on the review of boost_Atomic. Tim Blechman (author of supercollider) is the author of boost_lockfree but not boost_atomic on which it depends. As soon as these become a part of a boost release they would no longer require bundling

[1] https://svn.boost.org/trac/boost/wiki/ReviewScheduleLibraries

Attachments

oscpack_vs_sc_socpack.diff (13.0 KB) - added by bsjones 18 months ago.
comparison of oscpack upstream and sc bundled oscpack

Change History

Changed 18 months ago by bsjones

comparison of oscpack upstream and sc bundled oscpack

comment:1 Changed 18 months ago by bsjones

I have has discussions with oscpack upstream and resubmitted the supercollider patch and he seems willing to accept the changes. I have patched my review request accordingly and oscpack can be removed from this request.

Further to the boost_lockfree/atomic bundling request, I have since discovered that some of the supercollider plugins (sc3-plugins [1] which is essential) require these source headers to be present in the supercollider source tree.

[1] http://sc3-plugins.sourceforge.net/

comment:2 Changed 18 months ago by toshio

Some points in favour of allowing boost.{lockfree,atomic} to be bundled for a limited time:

One point against:

According to the website, boost releases four times a year.

Proposal: Allow bundling of lockfree and atomic through F20. If the libraries aren't in upstream boost that we ship in F21, package the two libraries into their own (sub)packages and link against those for F21. If I'm reading correctly, the upstream author of lockfree and supercollider are the same? If so, I'm fine with this being a subpackage of supercollider. A quick google seems to show that other projects are interested in using Atomic so an indefinite bundling exception doesn't seem wise.

comment:3 Changed 18 months ago by spot

  • Status changed from new to assigned
  • Owner set to spot

Allow bundling of lockfree and atomic through F20. If the libraries aren't in upstream boost that we ship in F21, package the two libraries into their own (sub)packages and link against those for F21. (+1:7, 0:0, -1:0)

comment:4 Changed 18 months ago by toshio

Note: The packages doing the bundling also need some Virtual provides. I can add these to the no bundled library page and they can be used in the packages.

  • bundled(boost-lockfree)
  • bundled(boost-atomic)

comment:5 Changed 18 months ago by toshio

announcement writeup:

supercollider was granted an exception to bundle boost-lockfree and boost-atomic through F20 (to be unbundled by F21 branch time). This allows time for merging of lockfree and atomic into the main boost release.

comment:6 Changed 13 months ago by limb

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.