Perisistance of chpl command

I recently rebuilt Chapel (quickstart) after changing distros, and the chpl command is not persisting over terminal sessions after completing the quickstart build.

I suspect the solution is to make install (or similar), as I found a relevant GitHub issue that seems to suggest this.

However, none of this info about non-persistence appears to be mentioned on the quickstart page in any of the sections. For example neither make install nor ./configure (which mentions installing) appear on that webpage. After building from source (even quickstart), I expected to be able to go try Chapel in other terminal sessions and I suspect others would expect this too.

I'm not sure how I was supposed to discover the proper way to get a persistent chpl, but I don't think it was by searching and finding a GitHub issue.

Did I totally miss something? If not, would it be possible to add a sentence or two concerning this topic to the quickstart guide?

Hi Gabriel —

Your reaction is not uncommon, so I would tend to agree with you that we should do something to improve this situation. We often chalk reactions like "When I opened up a new shell, chpl wasn't in my path anymore, why?!?" up to users who are not very UNIX-/bash-savvy, but I think you're correct that getting such users to the configure + install docs would also help them, while also making Chapel's build seem less special/different for people coming from an autoconf-based world.

I'm not going to try and defend the status quo, but I think that where you're supposed to learn about ./configure and make install is in the building.rst / building.html file (depending on whether you're using the documentation in the release or on the web) at the bottom, where this file is linked to from the bottom of the quick start documentation. But this is arguably problematic in a few ways:

(a) the quickstart instructions have started to say more and more beyond the "quick start" itself over time, such that users may not ever get to the "for more information" section, or feel that they need to (i.e., "I've already built the compiler, why would I read further instructions about how to do so?")
(b) even within the "building" file, it's the last thing mentioned, so anyone without a truly impressive attention span would be unlikely to find it before concluding that they were done.

I'd attribute the status quo in general, and item (b) in particular, as being likely due to the fact that most Chapel developers (and maybe power users as well?) tend not to use a configured + installed version of Chapel in practice, so it isn't something that many of us are subjected to most of the time. The configure + install option is also relatively new (in the grand scheme of the project history anyway), which is why it isn't mentioned more up-front in that file. Again, not saying these things to defend the status quo so much as explain them.

My own quick reaction to this is that we should pare the quickstart instructions back to the bare minimum to get a quick start, and then quickly defer to the more detailed documents (like "building") for follow-on information like "if you want the preferred configuration / if you want to install Chapel". But others (or you) may think differently about that, and I'd want to spend more time with these docs myself before putting any weight behind that opinion.

If you'd be interested in / willing to open a GitHub issue on our repository capturing your frustration / confusion here and asking for an improvement to the documentation, I think that would be great. If you have specific proposals for how to improve the organization or flow that you'd want to share on such an issue, I think that would be great as well.

Thanks again for posting this and pointing out this problem,

Thanks for the detailed response! I am working on the issue right now, so perhaps we'll continue the conversation there.

1 Like