[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 damian@…):

 Replying to [comment:11 ryandesign@…]:
 > I am looking into this now. I did not see your other messages before
 because I was not Cc'd on the ticket, but I'll Cc myself now since nobody
 else appears to be working on it.

 Thank you!

 >
 > The INSTALL file says cmake is the preferred build system here. Any
 reason why you didn't use that in the Portfile?

 Two reasons:
 1. We didn't want to add another dependency (on CMake) if there is a way
 to build with out it.
 2. The Portfile was developed by Alessandro, who maintains the Makefile,
 while I maintain the CMake system.  I have not looked into any details of
 the contents of the Portfile and did not ask Alessandro to learn the CMake
 set up so the separation of duties led to the choice of Make over CMake
 for the Portfile.

 >
 > We still haven't addressed the fact that we're not UsingTheRightCompiler
 and -arch flags here. Currently it tries to build with "gcc" (which could
 be anything on a user's system; we want RepeatableBuilds) and "mpicc"
 (which will not exist on user systems unless they have used "port select",
 and MacPorts ports are not allowed to use the results of "port select" in
 their own builds (and, with trace mode, would be prohibited from doing
 so)).

 Alessandro is new to writing a Portfile and I have no experience with it
 either.  If you have a suggestion to address this, please feel free edit
 the Portfile accordingly.

 >
 > So opencoarrays appears to require mpich in order to build. You've
 written the dependency to be on mpich-devel-gcc5, which depends on gcc5.
 Therefore we would not be able to accommodate #47426 which requests that
 opencoarrays be added as a dependency of gcc5, because that would
 introduce a circular dependency, which is not possible in MacPorts.

 I am glad to rescind #47426 and will look into whether I can do so.

 >
 > Any reason why you used mpich-devel-gcc5 (the potentially unstable
 development version) and not mpich-gcc5 (the stable version)? If either
 would work, we should use a [ticket:14540 path:-style dependency] (instead
 of a port:-style one) to allow the user to choose between the development
 or stable version, with preference for the stable one.

 That was a mistake on my part.  I believe either will work.

 >
 > 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 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.

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