Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
Hi Damian, > It would be difficult or impossible for several OpenCoarrays > developers to contribute without OpenCoarrays remaining separate for > several reasons. No, I understand that. What I meant is: do want to provide seamless integration, so that libgfortran builds would automatically detect if an MPI environment is available, and if so build opencoarrays. The only “hard" dependency is whether we have an mpicc, it seems. However, the big issue is that of build-time requirements, which are not compatible with GCC: opencoarrays depends on cmake and bash, so it is in that respect very different from GMP and MPFR, which do not have stricter requirement than GCC itself. I’ve started today to look at the OpenCoarrays source, and I admit I am quite lost… it seems that the build machinery is much larger than the source itself. Technically, it seems doable to OpenCoarrays a “Makefile.gfortran” that would build OpenCoarrays, without the need for bash or cmake. Does this sound right to you? >> 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. Currently, I don’t think we can integrate it in this form, due to build requirements. Maybe the threshold is lower for integrating it into GCC’s contrib scripts directory? FX
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
On 01/28/2017 03:22 AM, FX wrote: > Hi Damian, > >> It would be difficult or impossible for several OpenCoarrays >> developers to contribute without OpenCoarrays remaining separate for >> several reasons. > > No, I understand that. What I meant is: do want to provide seamless > integration, so that libgfortran builds would automatically detect if an MPI > environment is available, and if so build opencoarrays. The only “hard" > dependency is whether we have an mpicc, it seems. > > However, the big issue is that of build-time requirements, which are not > compatible with GCC: opencoarrays depends on cmake and bash, so it is in that > respect very different from GMP and MPFR, which do not have stricter > requirement than GCC itself. > > I’ve started today to look at the OpenCoarrays source, and I admit I am quite > lost… it seems that the build machinery is much larger than the source > itself. Technically, it seems doable to OpenCoarrays a “Makefile.gfortran” > that would build OpenCoarrays, without the need for bash or cmake. Does this > sound right to you? > > >>> 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. > > Currently, I don’t think we can integrate it in this form, due to build > requirements. Maybe the threshold is lower for integrating it into GCC’s > contrib scripts directory? > > FX > The script could certainly be part of the contrib scripts which use bash. On Fedora as an example there are gcc-gfortrn packages and mpich packages, ideally the package maintainers of gcc/gfortran could easily include libcaf-mpi, caf, and cafrun in the package. Or, of course a separate package could be developed. Whoever does the package could simply use the script to generate the targets. I have not encountered a system without cmake yet, I did test the script with my cmake missing to confirm that it does actually build cmake if needed before it proceeds, and then uses make. We have bash scripts already in libgfortran that get invoked either during configuration or by build. I don't see any real strong argument to not invoke the script with our make install as a normal process, perhaps with a --enable-opencoarrays during configuration. I would see that as a next phase after gcc7, in gcc8. Also keep in mind we have target systems that do not use the common software packaging methods and must rely on the gcc/gfortran build method, so this script is a way to "integrate" with minimal effect on gfortran source. It is in its own subdirectory, isolated from everything else and for gcc7 only manually invoked. This gets it out there, gets exposure, and gets it further tested. Since my original post, I have significantly cleaned up the script and have been testing on several platforms. I will post the cleaned up script later today. Jerry
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
> I have not encountered a system without cmake yet, I did test the script with > my > cmake missing to confirm that it does actually build cmake if needed before it > proceeds, and then uses make. We have bash scripts already in libgfortran that > get invoked either during configuration or by build. 1. We only have portable shell scripts currently in GCC trunk. Introducing a bash dependency would be new. 2. This would introduce a dependency on cmake, just like gmp and mpfr. Yes, it can automatically download it, but only if you’re not offline. Moreover, some package managers (e.g. homebrew) don’t allow installation scripts to download stuff from the network, for safety reasons. So it does count as a dependency. Given that OpenCoarrays is just a few source files, I don’t see why it couldn’t be compiled with a simpler process. I’m not asking the project to switch over, but we should be able to provide, under certain assumptions, a configure / make process that works. > Also keep in mind we have target systems that do not use the common software > packaging methods and must rely on the gcc/gfortran build method, so this > script > is a way to "integrate" with minimal effect on gfortran source. It is in its > own subdirectory, isolated from everything else and for gcc7 only manually > invoked. This gets it out there, gets exposure, and gets it further tested. If we ship it, we support it, and I don’t think we should introduce another whole build system into GCC. There already are scripts that exist, which Damian regularly advertise on comp.lang.fortran, which do this job. If opencoarrays can’t be made to fit within our current build system, I’d rather have that (integrate gcc build into opencoarrays) than the reverse (integrate opencoarrays build into gcc). In any case, thanks for exploring it. I really think we should find a way to integrated tightly the coarray features into gfortran, but we need to find the right technical solution. FX
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
> But ultimately there is a tight coupling between OpenCoarrays and GFortran; > it would be good to integrate OpenCoarrays into the GFortran testing > process... so that you can see when GFortran devs do something that triggers > a bug in OpenCoarrays, or that has a side effect of breaking OpenCoarrays > (GFortran bug, or coordination required to update interface etc. on > OpenCoarrays side.) I read through the OpenCoarrays source code, and I was surprise how tightly integrated it is with gfortran/libgfortran assumptions. Given that, how can it work with other compilers? > (*ducks while someone throws something at me for saying CMake is better than > auto tools*) > Any build system integrated with GCC should just be invoking CMake directly… I have absolutely no religion on the issue of cmake vs. autotools, I am just saying that GCC is a super-complex piece of code, which runs on tons of different platforms, and so is very conservative about its requirements. FX
