Closed tadkollar closed 1 year ago
I wonder if we should start versioning this now...
Probably... does anything need to change in this PR for that?
good question.. I guess it depends if we want to go ahead and do a more formal release process (tagging, etc.) or just keep it loose.. I suppose tagging is a good idea so that users could pick an older version if something breaks.. so maybe tag the existing version.. merge.. then tag a new version?
Hmm... I'd probably call the old build_pyoptsparse.sh
script version 1.x, and this version 2.x. Should we increment the minor version with each PR?
Your v1/v2 logic makes sense to me.. IMO it's completely up to you as the architect...
Not sure if tagging every PR is worth it, although changes are pretty infrequent so maybe... could just do it when enough "significant" bug fixes or a new feature is added?
Technically bug fixes would be a patch increment, and you would only increment the minor version for a new feature.. not that it's clear how that applies to a make system... I think this one is all "bug fixes"?
I was just wondering about it having the potential to break in somebody's environment and how they would go back to a version that works...
I think we might as well increment the patch version with each change and tag it. Like you said, there aren't many changes. I'd tag the original, bash-only script as 1.0, the current version as 2.0, and this PR can be 2.0.1. I'll add an __init__.py
to set __version__
and update setup.py
to extract that.
On some platforms, linking MUMPS with
-lm
is required but wasn't being performed by the MUMPS build, resulting in an error. This fix adds-lm
to the list of libraries linked against.Also, building MUMPS with a make program other than GNU make can cause the build to fail because Fortran modules are not built before they're needed. This adds a warning when GNU make is not found. It also checks for the availability of
gmake
and checks theMAKE
environment variable.There are several additional cleanups and description improvements.
Resolves #36 Resolves #37