Build system produces bad `link_args` variable in caf script

[milancurcic]

The build system seems to produce bad link_args variable in caf script when configured for gfortran. Once compiled and installed, the caf script contains the following line:

link_args=-fcoarray=lib -lcaf_mpi

which makes caf not work properly:

$ caf -w
/opt/opencoarrays/gcc-5.1.1/mpich-3.1.4/bin/caf: line 37: -lcaf_mpi: command not found
caf wraps CAFC=mpif90

The link_args variable needs to be enclosed in double quotes:

link_args="-fcoarray=lib -lcaf_mpi"

The caf script now works as expected:

$ caf -w
caf wraps CAFC=mpif90

The fix is to simply edit the src/mpi/CMakeLists.txt file to include the double quotes for link_args.

[milancurcic]

Pull request https://github.com/sourceryinstitute/opencoarrays/pull/20 will fix the issue.

It seems like the issue has been introduced with the commit https://github.com/sourceryinstitute/opencoarrays/commit/c98df6bd323fb55a9b28c1d5ca673ed06f9e49fc

[rouson]

Yes. I corrected this yesterday and hope to post a new release tonight. Please let me know which version you're using. You can get the version from

caf --version

or by looking at the "project" statement near the beginning of the top-level CMakeLists.txt file.

D

Sent from my iPhone

On Nov 11, 2015, at 2:32 PM, Milan Curcic notifications@github.com wrote:

The build system seems to produce bad link_args variable in caf script when configured for gfortran. Once compiled and installed, the caf script contains the following line:

link_args=-fcoarray=lib -lcaf_mpi which makes caf not work properly:

$ caf -w /opt/opencoarrays/gcc-5.1.1/mpich-3.1.4/bin/caf: line 37: -lcaf_mpi: command not found caf wraps CAFC=mpif90 The link_args variable needs to be enclosed in double quotes:

link_args="-fcoarray=lib -lcaf_mpi" The caf script now works as expected:

$ caf -w caf wraps CAFC=mpif90 The fix is to simply edit the src/mpi/CMakeLists.txt file to include the double quotes for link_args.

— Reply to this email directly or view it on GitHub.

[milancurcic]

Hi Damian,

$ caf -v | head -n 2

OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 2.0.0)

The issue is present in the latest opencoarrays master branch, cloned this afternoon.

[sourceryinstitute]

On Nov 11, 2015, at 4:04 PM, Milan Curcic notifications@github.com wrote:

Hi Damian,

$ caf -v | head -n 2

OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 2.0.0) Interesting. The caf script functions as if it were a compiler, but it gets built during the OpenCoarrays build process. That makes testing a little challenging because the solution is described on the main page of the AdHoc project: https://github.com/sourceryinstitute/AdHoc. However, my initial vision for caf involved it only being used with compilers that are unaware of OpenCoarrays and so I think the tests of the caf script only get generated in that scenario, which currently means only with gfortran 4.9 because that’s the only non-OpenCoarrays-aware compiler we currently support. You’ve made me realize there needs to be a test of the caf script that always gets built because we ultimately decided to recommend the use of caf even if the compiler is aware of OpenCoarrays.

Thanks again for this report!

Also, I’ve mostly been working on the release branch lately and so haven’t tested the master branch as often and I probably only applied my fix to the release branch. I’ll apply it to the master branch too now.

Damian

[milancurcic]

OK, I wasn't aware of the release branch until you just mentioned it. Any reason I should use one over the other? I've been using the master branch for a small toy project, no real issues so far.

[rouson]

On Nov 11, 2015, at 9:10 PM, Milan Curcic notifications@github.com wrote:

OK, I wasn't aware of the release branch until you just mentioned it. Any reason I should use one over the other? I've been using the master branch for a small toy project, no real issues so far.

Short answer: the master branch is for OpenCoarrays contributors. The release branch is for OpenCoarrays users.

The really long answer:

The master branch is where major new features are posted when they are still considered experimental.

The release branch is primarily for bug fixes and minor new features that are unlikely to break any pre-existing feature or previously tested user code.

On a related note, the “x.y.z” release numbering system essentially represents “major.minor.patch". Thus, incrementing x implies the addition of major new features, incrementing y implies the addition of minor new features, and incrementing z implies fixing bugs or updating documentation. That hopefully explains why the master branch is 2.0.0. As an example, we recently added support for exploiting GPUs using CUDA on the master branch. That feature will never appear in the 1.y.z series of releases. Our approach is a slight variation on Semantic Versioning (see http://semver.org). The primary difference is that I hope we won’t break the API as often as we’ll likely release major versions (probably annually).

FYI,

1.1.0 added scripts for building OpenCoarrays prerequisites . 1.2.0 will combine the prerequisite-building scripts buildcmake, buildmpich, etc., into one general “build” script capable of building anything in the software stack that supports OpenCoarrays 1.2.0 will also add an “install.sh” script that will facilitate building OpenCoarrays with the single-word command “./install.sh”, which will invoke the “build” script if necessary for building prerequisites.

Damian

[milancurcic]

Resolved by commit https://github.com/sourceryinstitute/opencoarrays/commit/ef5b51103c19446e6a1b23a7aa1acf8496ddd6c7.