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

CMake: Some minor cleanups #5948

Merged
merged 2 commits into from
Sep 26, 2023
Merged

CMake: Some minor cleanups #5948

merged 2 commits into from
Sep 26, 2023

Conversation

jgfouca
Copy link
Member

@jgfouca jgfouca commented Sep 21, 2023

Remove OS concept from cmake macros. We can maybe remove it entirely from config_machines but that will be trickier.

Remove some unneeded or repeated things from CMakeLists.txt.

Remove FMS dependency support.

[BFB]

Remove OS concept from cmake macros. We can maybe remove it entirely
from config_machines but that will be trickier.

[BFB]
@jgfouca jgfouca added BFB PR leaves answers BFB CMake build system labels Sep 21, 2023
@jgfouca jgfouca requested review from bartgol and sarats September 21, 2023 22:13
@jgfouca jgfouca self-assigned this Sep 21, 2023
cmake_minimum_required(VERSION 3.9)
cmake_policy(SET CMP0057 NEW)
set(CMAKE_CXX_STANDARD 17)

# Store caseroot in the cache, so that, if cmake re-runs,
Copy link
Member Author

@jgfouca jgfouca Sep 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CASEROOT is already always passed to cmake via -DCASEROOT=xxx so is already guaranteed to be in the cache. @bartgol , you had a commit that added this so maybe you can remember something I don't.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really recall. Maybe I wanted to have a doc string in CMakeCache.txt (which you don't get with -Dblah only)? Long stretch though...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But while we're on it, I think it's good practice to add

set (XYZ val CACHE TYPE doc)

for the CACHE vars that e3sm expects to receive. It is a way for our cmake files to self-document themselves. Otherwise one has to know how CIME will invoke cmake to figure out what comes from where...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bartgol , thanks. I will add that to the list of objectives for the full refactor.

@@ -127,16 +119,14 @@ list(APPEND CMAKE_MODULE_PATH ${CIMEROOT}/CIME/non_py/src/CMake)

set(CMAKE_VERBOSE_MAKEFILE TRUE)

if(USE_CUDA)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was already being done like 20 lines above.

# Scream manages its own flags
build_eamxx()

# We do want CMAKE_BUILD_TYPE to be set, but we do NOT want CMake to
# decide what optimization flags to append, based on build type,
# for components who rely on CIME for build flags, so make all the following empty.
# JGF: I think we can remove this once proper CMake names are being used in the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I think the mach files should set these variables to some reasonable values.

Copy link
Contributor

@bartgol bartgol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm always excited when the lines removed are more than those added in a PR!

@jgfouca jgfouca mentioned this pull request Sep 22, 2023
49 tasks
Copy link
Contributor

@mahf708 mahf708 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove in a consistent way (i.e., including entries in config_machines.xml) or leave redundant/unused stuff until we figure out a way to remove things cleanly.

@jgfouca
Copy link
Member Author

jgfouca commented Sep 25, 2023

@mahf708 , the sharedlibs builds still potentially use OS but that doesn't mean we have to use it in our cmake macros.

jgfouca added a commit that referenced this pull request Sep 25, 2023
CMake: Some minor cleanups

Remove OS concept from cmake macros. We can maybe remove it entirely
from config_machines but that will be trickier.

Remove some unneeded or repeated things from CMakeLists.txt.

Remove FMS dependency support.

[BFB]

* jgfouca/cmake_minor_cleanups:
  Remove FMS support
  CMake: Some minor cleanups
@jgfouca jgfouca merged commit 13c5352 into master Sep 26, 2023
@jgfouca jgfouca deleted the jgfouca/cmake_minor_cleanups branch September 26, 2023 16:21
@mahf708
Copy link
Contributor

mahf708 commented Sep 29, 2023

@jgfouca I had an issue with you removing the linux-generic cmake files, but not removing the linux-generic "machine" entry in config_machines.xml. I don't think it is a healthy practice to keep inconsistent or half-working stuff around, that's why I suggested removing the linux-generic MACH entries as well, unless there is a need.

  <machine MACH="linux-generic">
    <DESC>Linux workstation or laptop</DESC>
    <NODENAME_REGEX>none</NODENAME_REGEX>
    <OS>LINUX</OS>
    <COMPILERS>gnu</COMPILERS>
    <MPILIBS>openmpi,mpich</MPILIBS>
    <CIME_OUTPUT_ROOT>$ENV{HOME}/projects/acme/scratch</CIME_OUTPUT_ROOT>
    <DIN_LOC_ROOT>$ENV{HOME}/projects/acme/cesm-inputdata</DIN_LOC_ROOT>

I don't really know what the OS stuff is all about, because I was looking at MACH entries strictly speaking. Maybe they're being used interchangeably in confusing ways?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BFB PR leaves answers BFB CMake build system
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants