On September 21, 2018 6:24:45 PM GMT+02:00, Jerry DeLisle <jvdeli...@charter.net> wrote: >My apologies for kidnapping this thread: >On 9/20/18 1:01 PM, Thomas Koenig wrote: >> Hi Damian, >> >>> On a related note, two Sourcery Institute developers have attempted >to >>> edit >>> the GCC build system to make the downloading and building of >OpenCoarrays >>> automatically part of the gfortran build process. Neither developer >>> succeeded. >> >> We addressed integrating OpenCoarray into the gcc source tree at the >> recent Gcc summit during the gfortran BoF session. >> >> Feedback from people working for big Linux distributions was that >they >> would prefer to package OpenCoarrays as a separate library. >> (They also mentioned it was quite hard to build.) > >I would like to put in my humble 2 cents worth here. > >OpenCoarrays was/is intended for a very broad audience, various large >systems such as Cray, etc. I think this influenced heavily the path of >its development, which is certainly OK. > >It was/is intended to interface libraries such as OpenMPI or MPICH to >gfortran as well as other Fortran compilers. > >The actual library source code is contained mostly in one source file. >After all the attempts to integrate into the GNU build systems without >much success my thinking has shifted. Keep in mind that the >OpenCoarrays >implementation is quite dependent on gfortran and in fact has to do >special things in the build dependent on the version of gcc/gfortran a >user happens to use. I dont think this is a good situation. > >So I see two realistic strategies. The first is already talked about a > >lot and is the cleanest approach for gfortran: > >1) Focus on distribution packages such as Fedora, Debian, Ubuntu, >Windows, etc. Building of these packages needs to be automated into the > >distributions. I think mostly this is what is happening and relies on >the various distribution maintainers to do so. Their support is >greatly >appreciated and this really is the cleanest approach. > >The second option is not discussed as much because it leaves >OpenCoarrays behind in a sense and requires an editing cycle in two >places to fix bugs or add features. > >2) Take the one source file, edit out all the macros that define >prefixes to function calls, hard code the gfortran prefixes etc and >fork >it directly into the libgfortran library under GPL with attributions to > >the original developers as appropriate. > >Strategy 2 would lock into specific current standard versions of the >MPI >interface and would support less bleeding edge changes. It would also >require either OpenMPI or MPICH as a new gfortran dependency for >building, which not all users may need. So we would need some >configuration magic to enable or disable this portion of the build. >Something like --with-MPI-support would do the trick. > >Strategy 2 does add burden to gfortran maintainers who are already >overloaded. But, as the code matures the burden would decrease, >particularly once TEAMS are finished. > >Strategy 2 does have some advantages. For example, eliminating the need > >for separate CAF and CAFRUN scripts which are a wrapper on gfortran. >The coarray features are part of the Fortran language and gfortran >should just "handle it" transparently using an environment variable to >define the number of images at run time. It would also actually >eliminate the need to manage all of the separate distribution packages. > >So from a global point of view the overall maintanance effort would be >reduced. > >Strategy 2 would enable a set of users who are not focused so much on >distributions and loading packages, etc etc and those who are dependent > >on getting through bureaucratic administrations who already are loading > >gfortran on systems and would not have to also get another package >approved. People would just have to stop thinking about it and just >use it. > >So I think there are real advantages to Strategy 2 as well as Strategy >1 >and think it should be at least included in discussions. I would even >suggest there is likely a combination of 1 and 2 that may hit the mark. > >For example, keeping OpenCoarrays as a separate package for bleeding >edge development and migrating the stable features into libgfortran on >a >less frequent cycle.
Sounds reasonable to me. License issues will be the most difficult here given integration with libgfortran likely requires a FSF copyright rather than just a compatible license. Richard. >As I said, my 2 cents worth. > >Regards to all, > >Jerry
