On Feb 10, 2011, at 7:52 AM, Vicente Botet wrote:
Daniel Larimer wrote:
On Feb 10, 2011, at 3:34 AM, Oliver Kowalke wrote:
Am 10.02.2011 02:10, schrieb Daniel Larimer: Considering the degree to which we appear to be collaborating with respect to Mac OS X support, I would like to establish an easier development process based upon:
https://github.com/bytemaster/Boost.CMake
I have started a module for Boost.Context https://github.com/bytemaster/boost_context and will be creating modules for fiber, task, move, and other unofficial dependencies. If you would consider working with me to adopt CMake based modular approach to developing these libraries, I would greatly appreciate it. Otherwise, it it just too difficult to collaborate and do Mac OS X testing for you under the BJam monolithic zip-file based patches.
At the moment the module only works for libtask supported OS's. I need to add the CMake options to conditionally compile your various fcontext implementations.
Oliver is working already in a github repository. Maybe you can work together in his current repository. Oliver?
You could setup the CMAKE build chain and update the Mac part.
I am still learning git ( I like what I see ). I did check out his git-hub repository, but I was unable to figure out how 'overlay' his repos on a working boost chain or pull out just the parts he was using. Besides, I would like to support the efforts of Boost.CMake and/or Ryppl, both of which use cmake and a 'modular' approach allowing me to checkout 'just boost context' all in one directory and then collaborate on that repository. Because git does not allow you to manage externals in the same way subversion does (pointing at any subtree of the repo), it makes sense to keep each library in a self contained git module that does not split itself into boost/context and lib/context parts. Right now I see advantages in Boost.Cmake over Ryppl in that Ryppl is more tied to git, where as Boost.Cmake is more flexible with respect to getting the sources. I have checked out and built the projects for both and it seems like, in the short term Boost.CMake has the advantage over Ryppl, but in the long-term I think Ryppl will be the best. Either way, the module structure should be fairly close, thus making it easy to port from one system to the other or even support both at once. In this way we can give feed back to the developers working on these ideas. Is anyone doing active development of their boost components under either of these modular systems? Anyway, I agree with the creator of Ryppl when he said at Boostcon 2010 that the boost build process sucks the joy out of development. I want to focus on actual code, not fighting with a difficult boost-centric build system that cannot even handle (on Mac OS X ) passing bjam extra options required by Boost.Context without messing up the commands fed to sh. I have already spent 16+ hours just trying to get my 'environment' set up in a way that I can efficiently stay up to date with the trunk, submit patches that are easily merged, and work on my own private libraries. Perhaps a veteran boost developer could share their 'day-to-day' process for staying up to date, making patches, etc. Perhaps it is not so bad if you know bjam through and through.
HTH, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/fiber-mini-review-symmetric-a-asymmetric-... Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost