public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Damian Rouson <damian@sourceryinstitute.org>
To: sgk@troutmask.apl.washington.edu
Cc: fortran@gcc.gnu.org
Subject: Re: [PATCH] Implementation of RANDOM_INIT from F2018
Date: Fri, 12 Jan 2018 05:52:00 -0000	[thread overview]
Message-ID: <CACR8rvfzDRH+K+2s5THTRPBsD+GDhP9KD_joqJuXq6cQ91mRQA@mail.gmail.com> (raw)
In-Reply-To: <20180112041658.GA41743@troutmask.apl.washington.edu>

Thanks for the details. I will copy this feedback into an issue on the
OpenCoarrays repository and we will address each concern. My guess is that
the documentation to which you're referring is in GitHub-flavored Markdown
(.md file name extensions). If so, then hopefully there's a comment in the
first line of each file stating that the file is best viewed in a browser
at a provided URL.  Markdown is a server-side technology so it renders
correctly when served by the web site that hosts it.  Markdown is intended
to be more lightweight and readable without a browser than HTML, but I
think your feedback is telling me that we might have gone too far in using
lots of features that make the document look nicer online but look
confusing when viewed as raw text.

One of the most difficult challenges has been trying to support everyone's
preferred installation method yet keep the documentation terse, which is
why the documentation is not at all terse.  For every installation method
we offer, I know specific users who swear by that one approach to the
exclusion of all others.  We have users who won't touch CMake or our bash
script and will only use a static Makefile.  We have users who will only
use package management or even will only use one specific package manager
even if their platform supports several. And we have users who will only
use our bash installer.   Maybe we should stop trying to be all things to
all people.

The good news is that I hope this will all be moot in a few months. A
graduate student is coming to work with me for 12 weeks this Spring and is
keen on finishing the great work Jerry did to integrate the downloading and
building of OpenCoarrays into the GCC build system. After that, it should
be the case that anyone who installs gfortran by whatever method they
choose will automatically get OpenCoarrays installed too.  Then the only
reason anyone would ever need to install OpenCoarrays separately would be
if they want to do something unusual such as use OpenSHMEM instead of MPI.


Damian

On January 11, 2018 at 8:16:58 PM, Steve Kargl (
sgk@troutmask.apl.washington.edu) wrote:

> I apologies for letting my frustration boil over in email.
>
> It shouldn't take 4+ hours to wade through documentation
> to install a piece of software. The documentation in the
> release tar file is in some strange not-quite HTML language.
>
> One example of the issues. I have cmake 3.10.1 installed.
> cmake is available through my default path. install.sh wanted
> to download and use (install?) cmake 3.4.0. install.sh --help
> tells me that one can use "-m [arg]" or "--with-cmake [arg]",
> but there is no description of what arg ought to be. Should
> it be /usr/local or /usr/local/bin or /usr/local/bin/cmake?
>
> What is even more frustrating is the "-f [arg]" or
> "--with-fortran-compiler [arg]" option. At least one can infer
> that arg is the Fortran compiler or is it? My Fortran compiler
> is invoked from a Bournce shell script, gfcx, that insures
> gfortran picks up the right libraries. I used gfcx to build
> OpenMPI 3.0.0 and mpfi90 and mpifort correctly wrap gfcx. It
> didn't matter if I set arg to $HOME/bin/gfcx or $HOME/work/bin/mpif90
> (or mpifort), cmake died with an *emergency error* because gfortran
> was not "properly wrapped with MPI". Oddly, the command line
> reported by cmake was exactly what one expects from mpif90.
>
> --
> steve
>
>
> On Thu, Jan 11, 2018 at 07:11:25PM -0800, Damian Rouson wrote:
>
> I have no idea to what you're referring and I would have at least hoped
> for
> a nicer response after investing the time of trying to be helpful.
> Hopefully I'll remember to not make that mistake again. There many ways to
> install OpenCoarrays. I only mentioned one. Probably the simplest is
> package management, but I didn't want to suggest something that would
> require installing a package manager before installing OpenCoarrays so I
> suggested our installer, which I know many people use successfully and
> which I run refukarkrh, including on bare metal hundreds of times. We've
> attempted to respond to all the many ways people prefer to install and
> attempted to support a multitude of options. A simple issue report would
> be a lot more helpful and nicer than "broken beyond my patience."
>
> On January 11, 2018 at 4:53:55 PM, Steve Kargl (
> sgk@troutmask.apl.washington.edu) wrote:
>
> On Tue, Jan 09, 2018 at 05:10:42PM -0800, Steve Kargl wrote:
>
> On Tue, Jan 09, 2018 at 03:33:24PM -0800, Damian Rouson wrote:
>
> Hi Steve,
>
> Here are the results of compiling with the OpenCoarrays “caf”
> compiler wrapper, which uses -fcoarray=lib -lcaf_mpi:
>
>
>
> Well, I was going to try to save you time and me more
> headaches than I've already caused on the J3 mailing
> list. Installation of OpenCoarray is broken beyond my
> patience.
>
> --
> Steve
>
>
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
>

  reply	other threads:[~2018-01-12  5:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08  2:52 Steve Kargl
2018-01-09  0:58 ` Steve Kargl
2018-01-09  1:33   ` Damian Rouson
2018-01-09  2:03     ` Steve Kargl
2018-01-09 23:33       ` Damian Rouson
2018-01-10  1:10         ` Steve Kargl
2018-01-12  0:54           ` Steve Kargl
2018-01-12  3:11             ` Damian Rouson
2018-01-12  4:17               ` Steve Kargl
2018-01-12  5:52                 ` Damian Rouson [this message]
2018-01-12  6:57                   ` Steve Kargl
2018-01-16 20:30                 ` Damian Rouson
2018-01-09  2:51   ` Jerry DeLisle
2018-01-09  3:21     ` Steve Kargl
2018-01-09 17:11     ` Steve Kargl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACR8rvfzDRH+K+2s5THTRPBsD+GDhP9KD_joqJuXq6cQ91mRQA@mail.gmail.com \
    --to=damian@sourceryinstitute.org \
    --cc=fortran@gcc.gnu.org \
    --cc=sgk@troutmask.apl.washington.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).