> 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
