Anthony Islas

> The [template for the complete PR message is in `.github/PULL_REQUEST_TEMPLATE`](https://github.com/wrf-model/WRF/blob/master/.github/PULL_REQUEST_TEMPLATE). > > An alternate solution, and the one I chose in #1812, would be to set `USENETCDFPAR=0` in `configure`...

@weiwangncar Definitely 4.5.2 as this is a bug fix.

Modifications to `configure` are to be superseded by #1743 Modifications to `main/depend.common` are to be superseded by #1950

@weiwangncar I have one revision request left which should fix MPI linking issues

@scrasmussen I tested out the latest commit updates ([d8bb163](https://github.com/wrf-model/WRF/pull/2009/commits/d8bb163b861686287f915a43abc005fd22210dd1)) but still got the same error: ``` [ 98%] Linking Fortran static library libWRF_Core.a [ 98%] Built target WRF_Core Scanning dependencies...

@scrasmussen Do you mind if we pull this out of draft mode to merge in? @mgduda @weiwangncar Do you two have any thoughts on pulling this in given the NCAR/wrf_hydro_nwm_public#741...

My understanding is the issue is part of WRF Hydro itself, but as this PR adds the capability to build it analogous to the standalone repo using CMake this may...

Could be related to #1950

@HathewayWill I'm not sure I follow how adding these flags: `-Wno-implicit-function-declaration -Wno-incompatible-function-pointer-types` solves the compilation issues as all they are doing is suppressing warnings, unless WRFDA or the new Intel...

Thanks @HathewayWill The first log seems to fail because module_gfs_machine is being compiled in parallel with module_bl_mynn_common, not before: ``` 2165 rm -f module_gfs_machine.G module_gfs_machine.bb 2166 rm -f module_bl_qnsepbl.G module_bl_qnsepbl.bb...