On January 26, 2017 at 9:12:36 AM, Jerry DeLisle (jvdeli...@charter.net(mailto:jvdeli...@charter.net)) wrote:
> On 01/26/2017 05:25 AM, FX wrote: > > > - I am a bit surprised by the complexity of the script… couldn’t we provide > > a Makefile for opencoarrays, to be compatible with our other build > > requirements? > As Jerry alluded, the script takes advantage of code form the bash3boilerplate project (https://github.com/zbeekman/bash3boilerplate/tree/add-use-case). Almost every time I’ve started writing a simple script without bash3boilerplate, I ultimately decided to use bash3boilerplate. Using bash3boilerplate makes the code more robust (e.g., preventing the use of unset variables) and more flexible (e.g., making it easy to add command-line arguments). > > > - do we want to work towards seamless implementation of coarrays into > > gfortran, or coexistence as a separate package (as is currently the case, > > for example in Mac Homebrew, where it ships as a separate — but compatible > > — package)? It would be difficult or impossible for several OpenCoarrays developers to contribute without OpenCoarrays remaining separate for several reasons. First, committing OpenCoarrays source to the gfortran repository would almost certainly cut off all possibility that another compiler would adopt the relevant code as its parallel runtime library for licensing reasons and that potential for future adoption by other compilers is a primary motivation of the Sourcery Institute support for OpenCoarrays. Also, Sourcery Institute has a government contract in which GitHub and the tools that integrate into GitHub (e.g., Travis-CI and Markdown) play a central role along with various git workflows (e.g., the GitHub Flow) so keeping OpenCoarrays on GitHub creates important synergies with other projects that makes it much easier to fund the development of OpenCoarrays. > > I think we do want to head toward seamless. I have explored even copying the > source directly into the caf directory of libgfortran and merging the .h > files, > but this takes some time to do and would leave two sets of sources to > maintain. From an end user perspective, building OpenCoarrays during the gfortran build strikes me as seamles and doing so matches the current practice with MPFR, MPIC, GMP, and ISL. Also, multi-image execution will always add at least one new external dependency in the form of a parallel communication library such as MPI. > Regarding things like Homebrew, or rpm packages, it will require us to learn > how > to do these packages which none of us know right now. I wonder if developing an OpenCoarrays rpm package would be a good task as part of a Google Summer of Code (SoC) project. February 9 is the application deadline for organizations seeking to host an SoC student and I’m interested in applying to host a student. If anyone can suggest other good projects related to gfortran and OpenCoarrays, please let me know. Several students have expressed interest. I’m especially interested in anything that increases the support for the Fortran standards. > > Ultimately, since multi images is part of the Fortran language, it should just > happen transparently with the gcc regular build process. We’re all in agreement here so hopefully Jerry’s submission will be approved. OpenCoarrays developer Zaak Beekman and I will be glad to answer any questions about the supporting scripts. A lot of work went into them and they have had a lot of user input through the bash3boilerplate project to which Zaak has contributed. Damian
