Merge latest install logic including m4 dependency into devel branch #105
Conversation
install.sh will now build m4 if any of each of the following is either not found has an insufficient version number: mpich->gfortran->flex->bison.
Reduced the installed gfortran version to the gcc 5 branch, effectively matching the script-installed version to the minimum version.
"./build gcc --default" now results in the download of a 5.3.0 release tar ball from the nearest mirror, instead of the previous svn checkout of the trunk (6.0.0). Any gcc build launched by install.sh now installs release 5.3.0. When invoking "build" by other means, e.g., at the command line, a development branch can be built by specifying the branch name (e.g., "./build gcc gcc-5-branch"). Not specifying a branch is equivalent to "./build gcc trunk".
The new install_prerequisites/check_version.sh script exits with an error status if the first argument names a package that returns a version number lower than the second version. Now install.sh calls check_version.sh to verify the cmake, flex, bison, and m4 versions, each of which reports version numbers in the format major.minor.patch at the end of the first line of output from invoking them with the sole argument "--version". TODO: handle version numbers in the major.minor format and then use check_version.sh to verify the version number returne dby "mpif90 -v". Currently install.sh instead uses "mpif90 --version" which returns the version number of the Fortran compiler that mpif90 wraps. No check on the version number of the MPI implementation itself is performed. See issue #104
Add m4 to dependency tree
Current coverage is |
| EDIT: I spoke too soon... I'll investigate on the command line, but please DO NOT MERGE yet... |
| OK, I think I found the source of the issue whereby Github was disallowing merging of In essence, my first comment, which I had struck through but since reverted, was correct, but I had turned on a Github setting that I thought would help keep us out of trouble, that actually had the opposite effect. |
| Taking a look at the "files changed" tab displays the desired changes to be replayed on top of 💥 |
Merge latest install logic including m4 dependency into `devel` branch
Pick up PR #103 in
develEDIT: I spoke too soon...
EDIT 2: My first comment was correct, but a "protected branch" setting was causing Github to suggest "updating" the PR branch (in this case
master) by merging the base branch (devel) into it, definitely not what we actually want to do... jeeshMuch simpler than merging
develintoadd-m4-to-dependency-treeand thenadd-m4-dependency-treeintodevel. 💡Git is also smart enough to know, since
develis based onmasterbut we intentionally made changes like bumping the project version number to 2.0.0 etc. not to change that back to 1.2.3 etc. 🎉I really need to address #29