-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update ufs_release_1.0 for macOS/GNU support, bug fixes for semi case-sensitive filesystems #40
Update ufs_release_1.0 for macOS/GNU support, bug fixes for semi case-sensitive filesystems #40
Conversation
macOS + GNU build
…to ufs_release_v1.0
…se from existing files)
See NOAA-EMC/NCEPLIBS#11 for more information, the merge procedure and associated PRs. |
@climbfuji - Is the removal of the two files Makefile and Makefile_lib in this PR related to your Issue 38 in EMC_post? Simply to remove duplicate filenames with upper/lower cases? I would like to confirm with @mkavulich that this is ok and that it does not change regular EMC_post build with our new community build structure we plan to implement soon. |
@fossell the ufs_release_1.0 branches are supposed to work with the NCEPLIBS umbrella build script for the purpose of the UFS public release(s), they are not intended to work with any other build script. |
@fossell just to add - if they do work for you or if they can be made to work without holding back the UFS release that's fine, but the main purpose is to get the NCEPLIBS umbrella build (aka NCEPLIBS superproject) to work. |
@climbfuji - Thanks for the clarifications. There were two branches made in EMC_post for ufs release, I was under the assumption ufs_public_release would be the authoritative branch, but it sounds like ufs_release_v1.0 is the preferred branch and naming convention? If yes, I will merge this PR and ufs can use ufs_release_v1.0 for testing. DTC is supposed to be merging in its build restructuring to help serve the community, I'm unclear how that is to be integrated into ufs. My preference would be to have ufs use the new build structure even if the ufs app doesn't leverage any build features from it, just so that the code/directory structures look the same to community end users whether they use it within ufs app or as standalone entity. I'll put this on the ufs app issue open related to this as it's more of an app level decision. |
Merge macOS/GNU updates from full-stack build into ufs_release_1.0.
Remove old GNU makefiles that differ from other existing files only in the case of the first letter (Makefile and makefile, Makefile_lib and makefile_lib), because this is incompatible with the case-preserving (but otherwise case-insensitive) macOS filesystem.