Dependency on git for building from source not fit for purpose. - Please fix the release archives/autogen script.

[DetlevCM]

I'm sure the developers know this autogen.sh-error well..

===> ERROR:   Submodule modules/hwloc is not checked out.
===> ERROR:   if you just git cloned this repository, run
===> ERROR:       git submodule update --init
===> ERROR:   to checkout the submodules.

This is the default state when downloading a release from github...

No, installing from the repos is not a good solution, and no, using git clone is not suitable either.
Please fix the release instead of providing a broken download.

For the reasons why:

In the case of research, it can be relevant to refer to specific versions of software. Of course one can hunt down a specific git tag, but archiving the tar.gz of a release for reference is a lot easier.
Installing whatever random (maybe working, maybe not) version is supplied with the operating system is thus also out of the question. Plus, different software may need different versions.
This brings me to the use-case where this is really needed: HPC. In this case, software is provided from a central mount that all nodes read. Over time, one also accumulates different versions of these libraries (And no, the old ones cannot be replaced, can you guarantee old codes and software will work on the new version?) which are loaded as per user requirements using a modules environment such as lmod.
So we now come back to requiring version numbers, specific releases - and ideally, also would like to archive a version for future reference (if it needs to be rebuilt for example) - and again, few things are easier than archiving a release.

So please can you work towards the source code release provided on github in the releases being code that can be successfully configured & compiled?

...and rant over... - Its just that I've just now run into this (possibly again) and am feeling a bit irritated by this error.
Hopefully it still incites discussions and changes?

(And yes, using git clone works just fine for local testing, but it really isn't suitable for a central hpc provision as per the points mentioned above.)

Edit: And as an edit, there is no configure-script in the release archive, which means the instructions to build from the readme cannot be applied... The configure-script is typically generated by the autogen.sh script...

[raffenet]

Which tarball are you downloading? The github autogenerated archives are not official releases and should not be used. Unfortunately I have not found a way to disable them from being shown to users. Check the official release tarballs uploaded to release pages: https://github.com/pmodels/mpich/releases/tag/v4.3.0rc2

[raffenet]

For the record: official GH discussion about the issue with these automatic tarballs and the confusion they cause users: https://github.com/orgs/community/discussions/6003.

[DetlevCM]

Which tarball are you downloading? The github autogenerated archives are not official releases and should not be used. Unfortunately I have not found a way to disable them from being shown to users. Check the official release tarballs uploaded to release pages: https://github.com/pmodels/mpich/releases/tag/v4.3.0rc2

I clicked on releases and picked the source-code.tar.gz from the assets - it is the only file that indicates that it is source code.

Edit: I just downloaded mpich-4.3.0rc2.tar.gz from your link - oh, it is also source code.
-> Often the assets are binary builds on github, so there is no reason why the tar.gz should be source code. (Well, if it were a binary, for what system? There is no indication.)

It may be clearer to explicitly include src in the archive name to make it clear that it is a source code release.
It may further be potentially useful to include this in the readme as well.
(And the first place I looked was actually the mpich website that doesn't provide a source code download, only precompiled rpms.)

And thank you for the linked issue. Indeed, it causes confusion and frustration.

[raffenet]

MPICH source releases are available on our website https://www.mpich.org/downloads/. Perhaps we can update the links to show the filename rather than http. That is relic from when we provided both http and ftp access.

[DetlevCM]

MPICH source releases are available on our website https://www.mpich.org/downloads/. Perhaps we can update the links to show the filename rather than http. That is relic from when we provided both http and ftp access.

I think its less the type but the content. Looking at it again it now makes sense the first is actually the source code...
-> But I'd go back to labelling. For HDF5 for example, the link is called "Click here to obtain code for all platforms".
With OpenFOAM the link in the menu for the source code is called "Source".

Basically, the labelling is unambiguous. - So adding some kind of reference to it being source code in the name or label of the file would help. -> Now I start reading the text, it even says "source code below" at the end. But its too small and hidden. When we build different source code, we tend to just grab the archive and check the readme for instructions (or not, because we built older versions n times) and run with it.
I could imagine making "source code/source distribution" a heading on the website followed by the links, that would improve clarity.