Introduction and Cray support. [config] [build] [atomic] [interprocess] [asio] [dump] [tr1]
Hello world, My name is Richard Dale. I work at Cray, Inc. My purpose here is to get the boost libraries and Cray C++ compiler to work and play together better. I have a couple of questions, but maybe some background first. The first thing I plan to do is fix up the existing config/compiler/cray.hpp and .../v2/tools/cray.jam files. With this done, both the static and dynamic versions of most buildable libraries build successfully. The second thing is to address cray specific issues in the libraries listed in the subject line. With the exception of tr1, these are all preprocessor changes to avoid inline assembly, which the cray C++ compiler does not support yet, and probably won't anytime soon. The tr1 change is to provide a Cray version of the macro BOOST_TR1_STD_HEADER_NAME. The third thing will be to "officialize" the cray compiler, so that it gets picked up and used by default when it is the default compiler on Cray systems. The target is to provide good support for Cray C++ in the 1.56 release. Once the configuration changes are done, we (Cray) will start running the regression tests on a regular basis. I'm a little uncertain as to how to proceed in the immediate term, especially given the impending conversion to git. The idea of compiler support is somewhat orthogonal to the notion of library support, and there doesn't seem to be a well defined concept of compiler owner. I seem to have couple of options. The first option would be to get as much done as possible pre-conversion. My assumption is that I would check everything into the trunk, (The library changes are pretty trivial), using Trac tickets to keep the library owners in the loop. I assume it is the individual library owners who take care of the merges from trunk to branches/release (master?), although I'm unsure where this falls on the continuum between ordinarily true and always true. The second option would be to wait until the cutover to git, and do the workflow for making changes to a library owned by someone else. This is probably the right thing, but I'm more fluent with svn than with git. So, I guess I'm looking for advice and consent here. Please straighten me out if there is something I seem not to understand. For what it's worth, I've made myself "champion" for the Cray compiler. I don't pretend to know everything, but if I can't figure something out, I probably know who to ask. I'll take any Trac tickets relating to Boost on Cray. Regards, Richard
On Oct 29, 2013, at 10:54 AM, Richard Dale <rsd@cray.com> wrote:
Hello world,
My name is Richard Dale. I work at Cray, Inc. My purpose here is to get the boost libraries and Cray C++ compiler to work and play together better.
Welcome!
I have a couple of questions, but maybe some background first.
The first thing I plan to do is fix up the existing config/compiler/cray.hpp and .../v2/tools/cray.jam files. With this done, both the static and dynamic versions of most buildable libraries build successfully.
This seems like a great first step.
The second thing is to address cray specific issues in the libraries listed in the subject line. With the exception of tr1, these are all preprocessor changes to avoid inline assembly, which the cray C++ compiler does not support yet, and probably won't anytime soon. The tr1 change is to provide a Cray version of the macro BOOST_TR1_STD_HEADER_NAME.
A good second step.
The third thing will be to "officialize" the cray compiler, so that it gets picked up and used by default when it is the default compiler on Cray systems.
The target is to provide good support for Cray C++ in the 1.56 release.
Once the configuration changes are done, we (Cray) will start running the regression tests on a regular basis.
Great! That's one of the key requirements for being a "supported" compiler; having a regression tester.
I'm a little uncertain as to how to proceed in the immediate term, especially given the impending conversion to git. The idea of compiler support is somewhat orthogonal to the notion of library support, and there doesn't seem to be a well defined concept of compiler owner.
I seem to have couple of options.
The first option would be to get as much done as possible pre-conversion. My assumption is that I would check everything into the trunk, (The library changes are pretty trivial), using Trac tickets to keep the library owners in the loop. I assume it is the individual library owners who take care of the merges from trunk to branches/release (master?), although I'm unsure where this falls on the continuum between ordinarily true and always true.
My suggestion is to open tickets with the problems that you see on your compiler, and attach patches to the tickets, and then work with the library owners to get the patches applied (first to the trunk, and then to release). John Maddock, for example, is the maintainer of the configuration library. [ A list of maintainers and their email addresses can be found in libs/maintainers.txt ]
The second option would be to wait until the cutover to git, and do the workflow for making changes to a library owned by someone else. This is probably the right thing, but I'm more fluent with svn than with git.
If you've got time and interest now, I wouldn't wait.
So, I guess I'm looking for advice and consent here. Please straighten me out if there is something I seem not to understand.
For what it's worth, I've made myself "champion" for the Cray compiler. I don't pretend to know everything, but if I can't figure something out, I probably know who to ask. I'll take any Trac tickets relating to Boost on Cray.
-- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Tuesday 29 October 2013 12:54:15 Richard Dale wrote:
Hello world,
Hello and welcome!
My name is Richard Dale. I work at Cray, Inc. My purpose here is to get the boost libraries and Cray C++ compiler to work and play together better.
I have a couple of questions, but maybe some background first.
The first thing I plan to do is fix up the existing config/compiler/cray.hpp and .../v2/tools/cray.jam files. With this done, both the static and dynamic versions of most buildable libraries build successfully.
The second thing is to address cray specific issues in the libraries listed in the subject line. With the exception of tr1, these are all preprocessor changes to avoid inline assembly, which the cray C++ compiler does not support yet, and probably won't anytime soon. The tr1 change is to provide a Cray version of the macro BOOST_TR1_STD_HEADER_NAME.
The third thing will be to "officialize" the cray compiler, so that it gets picked up and used by default when it is the default compiler on Cray systems.
The target is to provide good support for Cray C++ in the 1.56 release.
Once the configuration changes are done, we (Cray) will start running the regression tests on a regular basis.
That sounds like a great plan, especially the test running part.
I'm a little uncertain as to how to proceed in the immediate term, especially given the impending conversion to git. The idea of compiler support is somewhat orthogonal to the notion of library support, and there doesn't seem to be a well defined concept of compiler owner.
I seem to have couple of options.
The first option would be to get as much done as possible pre-conversion. My assumption is that I would check everything into the trunk, (The library changes are pretty trivial), using Trac tickets to keep the library owners in the loop. I assume it is the individual library owners who take care of the merges from trunk to branches/release (master?), although I'm unsure where this falls on the continuum between ordinarily true and always true.
The second option would be to wait until the cutover to git, and do the workflow for making changes to a library owned by someone else. This is probably the right thing, but I'm more fluent with svn than with git.
The preference for timing changes is after each library maintainers. Trunk is formally open for changes at any time, but I think it would be wise to delay the actual commits until after 1.55 is out. Given that the transition to git is scheduled shortly after, the second option seems the most appropriate to me. But don't let that stop you. You can start creating Trac tickets for each library with patches and discussing the suggested changes on this list. Just make sure the subject starts with the library name in square brackets to catch maintainer's attention. BTW, you can contact me and Tim Blechmann about Boost.Atomic. Once the transition to git is complete you'll have the option to create pull requests instead of Trac tickets, if that is more convenient for you. The typical workflow is you create a ticket with a patch, it gets reviewed and applied to trunk (if not rejected). Then it gets tested there and if the tests pass it is then merged to release. With SVN, the person who applied the patch to trunk would usually be the one who sees the patch all the way through to release. I suppose, with git this person will always be one of the library maintainers or release managers (no one else will have write access to the repository).
participants (3)
-
Andrey Semashev -
Marshall Clow -
Richard Dale