Skip to content
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

mk_scripts/mk_make is not general #3

Open
StevePny opened this issue Apr 13, 2022 · 1 comment
Open

mk_scripts/mk_make is not general #3

StevePny opened this issue Apr 13, 2022 · 1 comment

Comments

@StevePny
Copy link
Contributor

StevePny commented Apr 13, 2022

building in ubuntu docker container, gnu, arm64...

In mk_scripts/mk_make there are a few design choices making the build more challenging:
(1) It uses the 'module' command
(2) It depends on "${BUILD_ROOT}/site/environment.${COMPILER}.sh"
(3) Paths to FMSlib and nceplibs are relative
(4) Build itself, including exec and bin are put into the repo directory structure.

The file ${BUILD_ROOT}/site/environment.${COMPILER}.sh only has a few options, and they seem designed specifically for NOAA HPC:
(gaea, orion, jet, hera, lsc)

It would be helpful if the 'default' (i.e. the else clause) was a user-supplied set of parameters, and it could fail if one of the required parameters is not supplied (e.g. as an environment variable).

It would be my preference to have the paths to FMSlib and nceplibs specified as an environment variable, as they will generally either already be installed or will need to be installed by the user using the same compiler. Also, I think it is generally not good practice to build the model and libraries in the directory structure of the github repository. It's not a huge issue for me since I'm building in docker, but if I was doing direct development of SHiELD I would find this more difficult to deal with.

At the moment I'm fixing these issues with:
(1) ignore the module command - this doesn't seem to stop execution of the script
(2) I just remove the line referencing the environment.${COMPILER}.sh file (see below)

# Remove the template call in mk_scripts/mk_make
# and fix the library references in mk_scripts/mk_make
RUN cd ${BUILD_ROOT}/Build \
  && sed 's|. ${BUILD_ROOT}/site/environment.${COMPILER}.sh||' < mk_scripts/mk_make > OUT \
  && mv OUT mk_scripts/mk_make \
  && sed 's|../../libFMS/${COMPILER}/${bit}|${FMS_DIR}/lib|' < mk_scripts/mk_make > OUT \
  && mv OUT mk_scripts/mk_make \
  && sed "s|../../nceplibs/\${COMPILER}/|${NCEPLIBS_DIR}/lib|" < mk_scripts/mk_make > OUT \
# && sed "s|../../nceplibs|${BUILD_ROOT}/Build/nceplibs|" < mk_scripts/mk_make > OUT \    #STEVE: this is what gfdl wants but I don't think this is possible
  && mv OUT mk_scripts/mk_make \
  && sed "s/-lbacio_4  -lsp_v2.0.2_d  -lw3emc_d  -lw3nco_d/-lbacio_4  -lsp_d  -lw3emc_d  -lw3nco_d/" < mk_scripts/mk_make > OUT \
  && mv OUT mk_scripts/mk_make \
  && chmod 755 mk_scripts/mk_make

(3) updated in code shown above
(4) I move the executable to an external bin directory that still exists after reducing the docker build to a more minimal image:

  && mv exec/${FV3_config}_${FV3_compiler}/test.x ${SHiELD_BIN}/${FV3_config}_${FV3_hydro}.${FV3_comp}.${FV3_bit}.${FV3_compiler}.x
@bensonr
Copy link
Contributor

bensonr commented Apr 19, 2022

@StevePny - we don't see this as a major issue since the .gitignore file is set up to not track any files created as part of the executable build. Feel free to push any needed changes via a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants