Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran

[Damian Rouson <damian at rouson dot net>]

On January 26, 2017 at 9:12:36 AM, Jerry DeLisle
(jvdelisle@charter.net(mailto:jvdelisle@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