[MacPorts] #47806: OpenCoarrays @1.0
noreply at macports.org
Wed Jun 17 00:13:14 PDT 2015
#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
> 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-
> > 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
> 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,
Ticket URL: <https://trac.macports.org/ticket/47806#comment:24>
Ports system for OS X
More information about the macports-tickets