Conversation
src/gen.c - Modified routine GenerateUpdateRconst so that the INLINED RCONST contents will be placed immedately after the start of the UPDATE_RCONST subroutine, and to place F90 variable declarations etc. immediately after that. This will prevent compile-time errors if a USE statement is included via "INLINED RCONST", as USE statements must come before variable declarationas and other statements. - Updated comments CHANGELOG.md - Updated accordingly Signed-off-by: Bob Yantosca <[email protected]>
src/gen.c - Removed leftover comment about "int UPDATE_RCONST;" variable - Fixed typo Signed-off-by: Bob Yantosca <[email protected]>
|
We have this problem in the dev branch since and The solution in this PR works fine in the first case when the A possible solution could be to create a separate inlined type |
RolfSander
left a comment
There was a problem hiding this comment.
Maybe create F90_RCONST_USE?
|
@RolfSander: Yes, I thought of that after I went home after making the PR. I'll try to add a separate inline for USE statements. Thanks for the feedback! |
src/gdata.h - Declare F90_RCONST_USE as a variable of type "enum inl_code" src/scanner.c - Added F90_RCONST_USE to InlineKeys[] src/gen.c - In routine GenerateUpdateRconst we now proceed in this order: 1. Manually write the "SUBROUTINE UPDATE_RCONST ( YIN )" line 2. Inline code from the "#INLINE F90_RCONST_USE" section 3. Declare YIN optional argument and Y local variable 4. Copy values of YIN to Y (if necessary) 5. Inline code from the "#INLINE F90_RCONST" section 6. Manually write the "END SUBROUTINE UPDATE_RCONST" line .gitignore - Now ignore executable files in MCM example folders CHANGELOG.md - Updated accordingly Signed-off-by: Bob Yantosca <[email protected]>
|
@RolfSander: I modified the code in bd4745f so that we place |
RolfSander
left a comment
There was a problem hiding this comment.
Thanks, @yantosca for coding this so quickly! The code looks good, I
just have a few minor comments:
-
It would be good to mention the new inline type also in
docs/source/using_kpp/04_input_for_kpp.rst. -
You've added
/examples/mcm*/*.exeto.gitignore. I wonder if
there are any executable*.exefiles at all that we want in our
repo. If not, maybe we can exclude all*.exefiles in.gitignore? -
Currently, the following comment is inserted into the KPP-generated
files:Begin INLINED RCONST - F90 USE STATEMENTSMaybe it would be better to rename this to:
Begin inlined code from F90_RCONST_USEUsing the term "
F90_RCONST_USE" verbatim here would facilitate
finding the inlined code in the KPP-generated files. Similarly, I
think it would be good if the name appears verbatim also in the
comments created for the otherF90_*inline types.
If you agree but don't have the time to implement it now, let me know!
|
Thanks @RolfSander. I will make those edits before I merge the branch. Easy enough! |
.gitignore - Ignore all *.exe files src/gen.c - Updated commments where inlined code is added to be more descriptive (referencing F90_RCONST_USE and F90_RCONST) docs/source/using_kpp/04_input_for_kpp.rst - Added documentation for F90_RCONST_USE CHANGELOG.md - Updated accordingly Signed-off-by: Bob Yantosca <[email protected]>
|
Minor fixes based on your suggestions added in commit 2f97825 |
This is the companion PR to #119. In that issue we described how the
UPDATE_RCONSTroutine was generated such that a USE statement inINLINED RCONST:could cause a compiler error due to the
USEstatement not being first in the subroutine.This PR has edited the
GenerateUpdateRconstroutine insrc/gen.cto do the following:SUBROUTINE UPDATE_RCONST ( YIN )line#INLINE F90_RCONST_USEsectionYINoptional argument andYlocal variableYINtoY(if necessary)#INLINE F90_RCONSTsectionEND SUBROUTINE UPDATE_RCONSTlineThis will only affect the F90 output, which now looks like this:
which now compiles properly:
Closes #119