search

OpenMDAO / build_pyoptsparse

python script to build/install pyoptsparse with IPOPT (and optionally SNOPT)
Apache License 2.0
9 stars 15 forks source link

Link with `-lm`, check for GNU make #41

Closed tadkollar closed 1 year ago

tadkollar commented 2 years ago

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 the MAKE environment variable.

There are several additional cleanups and description improvements.

Resolves #36 Resolves #37

swryan commented 2 years ago

I wonder if we should start versioning this now...

tadkollar commented 2 years ago

Probably... does anything need to change in this PR for that?

swryan commented 2 years ago

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?

tadkollar commented 2 years ago

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?

swryan commented 2 years ago

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...

tadkollar commented 2 years ago

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.