-
Notifications
You must be signed in to change notification settings - Fork 120
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
Rename dirs and make executable dir switchable to meet NCO standards #216
Conversation
CMakeLists.txt
Outdated
@@ -91,6 +88,10 @@ SET(host_os "${osrel}") | |||
SET(abs_top_builddir "${CMAKE_CURRENT_BINARY_DIR}") | |||
SET(abs_top_srcdir "${CMAKE_CURRENT_SOURCE_DIR}") | |||
|
|||
##### Executable directory name (exec_bin): exec or bin ############# | |||
SET(exec_bin exec) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems hard-coded. The PR description says it is switchable, but I don't see any option for doing that at build time. Also, what is the point of having a configurable directory name for executables? Everything should be adjustable using $CMAKE_PREFIX_PATH
with its subdirs using standard software industry names. It seems to me that having a configurable directory name for the executables directory has no advantages and increases the complexity a lot. The complexity increases dramatically because now every other component in the App tree will need to support this. I need to be convinced that there is a good reason to make this configurable rather than just setting it to what it needs to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify, I think this should look like:
set(exec_bin "exec" CACHE STRING "Executable directory name")
or perhaps
set(exec_bin "exec" CACHE INTERNAL "")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also argue that the default should be bin
not exec
for the simple reason that NCO is the only place where exec
would be desired. The default should be the value that the community expects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christopherwharrop-noaa, I am not familiar with cmake. Can you help me for this? I'll invite you to my repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christopherwharrop-noaa, Now I got your point. I'll modify exec_bin soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christopherwharrop-noaa, a new cmake argument '-DEMC_EXEC_DIR' was introduced to change the dir name to 'exec' for the NCO standard. This is the same approach as UFS_UTILS and UPP. Its default is 'bin'. To change the name to 'exec', we just need to add "-DEMC_EXEC_DIR=ON" to CMAKE_SETTINGS as described in devbuild.sh (ln 213).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The appropriate solution would be to provide at cmake configuration time:
-DCMAKE_INSTALL_BINDIR=exec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also argue that the default should be
bin
notexec
for the simple reason that NCO is the only place whereexec
would be desired. The default should be the value that the community expects.
That is the default that CMake assigns.
devbuild.sh
Outdated
CLEAN=false | ||
CONTINUE=false | ||
VERBOSE=false | ||
# detect PLATFORM (MACHINE) | ||
source ${SRC_DIR}/env/detect_machine.sh | ||
source ${SRC_DIR}/modulefiles/detect_machine.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The contents of a directory named modulefiles
should probably contain module files. This is confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christopherwharrop-noaa, ok. I'll move it to another dir.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christopherwharrop-noaa, this file has been moved into the 'test' dir.
@@ -161,7 +161,7 @@ if [ "${VERBOSE}" = true ] ; then | |||
fi | |||
|
|||
# set ENV_FILE for this platform/compiler combination | |||
ENV_FILE="${SRC_DIR}/env/build_${PLATFORM}_${COMPILER}.env" | |||
ENV_FILE="${SRC_DIR}/modulefiles/build_${PLATFORM}_${COMPILER}.env" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're going to name this directory modulefiles
then all of the *.env
files should be converted to actual module files and should be loaded with, for example, module load build_hera_intel
rather than sourced. This would also remove the user's shell from the equation as the module load
would work regardless of the shell the user is using.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christopherwharrop-noaa, I agree. This will be my next PR. I don't want to put several topics into one PR. I'll modify the env files into the regular module files in another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christopherwharrop-noaa, if you want this change in this PR, I'll do it soon.
sorc/CMakeLists.txt
Outdated
##### CMAKE Arguments depending on exec_bin ######################### | ||
|
||
list(APPEND COMP_ARGS "-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}") | ||
if(${exec_bin} STREQUAL exec) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the point of supporting multiple names for the executable install directory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@christopherwharrop-noaa, the UFS SRW App will be used as an operational model. We should change the app to meet the NCO standards for this. If you and other reviewers agree, we can use only one name as 'exec'. But I don't think this is what you want.
I understand that the point of this PR is to make the ufs-srweather-app conform to NCO naming conventions. However, I can't in good conscience let this go by without expressing a few thoughts about that. I'd like to remind everyone that this is a community model, and as such, its development should always be guided by standard software industry practices and principles. Departures from well accepted ubiquitous industry standards should only be done for reasons that can be objectively evaluated and justified on their technical merits and which clearly demonstrate why the departure improves the codebase. Departures from industry standards present customers with unexpected attributes, features, and behaviors. This has at least two consequences: (1) Usability by the community is decreased because customers have to learn non-standard behaviors and quirks (2) Nonstandard nomenclature and naming conventions undermines the otherwise professional quality of the product; it may be harmful to the organization's reputation because it will not appear "professional". This may sound like a minor point, but the software industry has well established conventions for how the various parts of a code base are organized. NCO is absolutely an outlier when it comes to their naming convention standards. Literally no one else on Earth uses those conventions (e.g. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't approve until the following are addressed:
- A CMake option is added for the value of
exec_bin
needs to be chosen at build time with a CMake option or it is - Either the contents of
modulefiles
directory are changed to be actual module files or the directory is not named "modulefiles"
CMakeLists.txt
Outdated
@@ -91,6 +88,10 @@ SET(host_os "${osrel}") | |||
SET(abs_top_builddir "${CMAKE_CURRENT_BINARY_DIR}") | |||
SET(abs_top_srcdir "${CMAKE_CURRENT_SOURCE_DIR}") | |||
|
|||
##### Executable directory name (exec_bin): exec or bin ############# | |||
SET(exec_bin exec) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify, I think this should look like:
set(exec_bin "exec" CACHE STRING "Executable directory name")
or perhaps
set(exec_bin "exec" CACHE INTERNAL "")
@christopherwharrop-noaa, I understand what your point is. However, most users of the UFS SRW App and the regional workflow, including myself, are not familiar with the standard software industry practices and principles because their backgrounds are not software engineering or computer science. Only some knowledgeable people like you perceive it. I've never heard that 'bin' is the standard name for executables before. This might be my lack of knowledge. I don't care about the name of the executable directory. However, the NCO standards describe that the executable directory should be named to 'exec'. Simply put yourself in my position. There exists one standards describing the rules specifically even though it is only for one organization. Other institutes don't have standards like this. In this case, it will be more professional to follow the existing standards. I agree that it may be harmful to the organization's reputation. However, it is not something we can decide at this moment. I suggest you to meet the NOAA management group and update the standards with the software industry principles :) :) Can you share the standard software industry practices and principles with us if you have any documents? It will be definitely helpful at least for me to be a professional software engineer in the far future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments on the discussion of bin vs exec.
BTW, NCO does not object to src or bin vs sorc or exec.
I am not sure about the envs case.
Hope this helps.
# Executable directory name (exec_bin): exec or bin | ||
SET(exec_bin "bin") | ||
IF(EMC_EXEC_DIR) | ||
SET(exec_bin "exec") | ||
ENDIF() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be necessary.
@@ -119,7 +122,7 @@ MESSAGE(${UFS-SRWEATHER-APP_SETTINGS}) | |||
# Install ufs_srweather_app.settings file into same location | |||
# as the app. | |||
INSTALL(FILES "${CMAKE_BINARY_DIR}/ufs_srweather_app.settings" | |||
DESTINATION bin) | |||
DESTINATION ${exec_bin}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use ${CMAKE_INSTALL_BINDIR}
@@ -210,6 +210,7 @@ fi | |||
# cmake settings | |||
CMAKE_SETTINGS="-DCMAKE_INSTALL_PREFIX=${INSTALL_DIR}" | |||
CMAKE_SETTINGS="${CMAKE_SETTINGS} -DCMAKE_BUILD_TYPE=${BUILD_TYPE}" | |||
#CMAKE_SETTINGS="${CMAKE_SETTINGS} -DEMC_EXEC_DIR=ON" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead use
-DCMAKE_INSTALL_BINDIR=exec
where exec is desired.
If @aerorahul is correct that NCO doesn't object to the use of |
@christopherwharrop-noaa, @aerorahul is the right person who can confirm this. Since he said ok, I'll close this pr and submit a new one for modulefiles soon. |
DESCRIPTION OF CHANGES:
exec
andbin
. A PR pre-required for this is under review in NOAA-EMC/UPP.DEPENDENCIES:
ISSUE:
Fixes issue mentioned in #215