[MacPorts] #47806: OpenCoarrays @1.0

[MacPorts]

#47806: OpenCoarrays @1.0
-------------------------------+--------------------------------
  Reporter:  fanfarillo.gcc@…  |      Owner:  macports-tickets@…
      Type:  submission        |     Status:  new
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:  2.3.3
Resolution:                    |   Keywords:
      Port:  opencoarrays      |
-------------------------------+--------------------------------

Comment (by ryandesign@…):

 Replying to [comment:15 damian@…]:
 > > The port claims to download version 1.0 of the software, but the
 opencoarrays web site does not mention such a version. It just refers
 users to the github page to download. The github page doesn't have any
 tags. If this is really version 1.0, why isn't there a 1.0 tag in the
 repository? If the URL listed in the portfile's master_sites is an
 official download URL, why isn't it mentioned anywhere on the opencoarrays
 web site?
 >
 > Alessandro has been planning to post a version 1.0.  He is most likely
 going to be offline and away from work for the next couple of days, but
 I'll ask him to respond to these questions as soon as he returns. There is
 a chance he and I will talk tomorrow.  For now,  just pushed a commit to
 github that adds a "VERSION 1.0" argument to "project" statement in the
 top-level CMakeLists.txt file. This in combination with the subsequent and
 previously existing CMake write_basic_package_version_file command causes
 CMake to write package version information in a subdirectory of the "lib"
 installation directory.  If there is more that we should, please explain.
 In particular, I'm not sure how to what is meant by the phrase "a 1.0 tag
 in the repository."  Is this tag to appear in the README file or in a
 separate file or some other way?

 I mean: a tag in your git repository: http://git-scm.com/book/en/v2/Git-
 Basics-Tagging


 > > I tried adding a universal variant but it failed because the mpich
 dependency doesn't have a universal variant.
 >
 > I have no clue what this means -- hopefully Alessandro will -- but if
 you can provide more details, please do.  Please keep in mind that neither
 of us has any experience with writing a Portfile. Andy advice is welcome.

 A universal build is one that contains more than one architecture. For
 example, a non-universal build might contain code built for x86_64 only,
 while a universal build might contain code built for both x86_64 and i386.
 MacPorts implements universal builds via the variant mechanism. If we can
 add a universal variant to opencoarrays that would be great, but we may
 first need to address the lack of a universal variant in the mpich ports.


 Replying to [comment:16 fanfarillo.gcc@…]:
 > The CMake support has been added after I proposed the Portfile.

 Maybe we should investigate using it, since the project documentation says
 it is the recommended way. If so, the cmake 1.0 portgroup should be used.


 > Just to be clear, opencoarrays does not need gcc5 to build.

 I understand that. But your build script is currently trying to build with
 "gcc" (which is not allowed for the reasons explained in the
 UsingTheRightCompiler wiki page) and "mpicc" (which does not exist, which
 causes the build to fail with a "file not found" error for "mpicc").


 > We would like to keep the installation process as easy as possible
 (asking for a choice sounds less easy to me). Let's just use mpich-gcc5.

 When -devel ports are used correctly, installation when -devel ports are
 available is no more difficult than when they are not available, because
 MacPorts will automatically choose the non-devel version of a dependency
 unless the user has specifically requested the -devel version by
 installing it first.

 Unfortunately, the mpich -devel ports were not designed correctly, so we
 have no choice to use either the -devel version of the non-devel version,
 until #48086 is resolved. In light of that, I agree, let's use mpich-gcc5
 for now.


 > The tarball currently available from macport was a candidate version now
 obsolete. The plan was to release OpenCoarrays 1.0 as soon as this port
 was accepted. We still plan to do that; I should be able to work on the
 port tomorrow, after that, if all the changes will be accepted we can post
 the tarball of OpenCoarrays 1.0 on opencoarrays.org.

 The correct order of operations would be that you release a version of
 your software, then we add it to MacPorts, not the other way around.


 Replying to [comment:20 fanfarillo.gcc@…]:
 > gcc6 is even better. It contains some patches related with coarrays.

 Then the opencoarrays port should offer gcc5 and gcc6 variants, with gcc5
 being the default until gcc6 becomes stable.


 Replying to [comment:23 larryv@…]:
 > Ryan, have you worked on this any further? I can take over, if not.

 I'll attached my work in progress and hand it over to you at this point,
 Larry.

-- 
Ticket URL: <https://trac.macports.org/ticket/47806#comment:24>
MacPorts <https://www.macports.org/>
Ports system for OS X