capgen Fortran parser does not accept internal DDTs as part of a registered DDT

[climbfuji]

Description

Error:

Reading host model data from /path/to/mod_mytype.meta
table: 'linterp_table_t' is not a valid derived Fortran type, at /path/to/mod_mytype.meta:33
'
CMake Error at external/ccpp/CMakeLists.txt:135 (message):
  ccpp_capgen.py FAILED: result = 1

-- Configuring incomplete, errors occurred!

Fortran:

  !> Corresponding derived type mytype_dat_t
  !! \section arg_table_mytype_dat_t Argument Table
  !! \htmlinclude mytype_dat_t.html
  !!
  type mytype_dat_t
    type(linterp_table_t) :: table
...

Metadata:

[ccpp-table-properties]
  name = mytype_dat_t
  type = ddt
  dependencies = ../ccpp-physics/physics/tools/mpiutil.F90,mod_utils.F90
  module_name = mod_mytype

[ccpp-arg-table]
  name = mytype_dat_t
  type = ddt

The type linterp_table_t is defined in the dependency mod_utils.F90 and is nowhere exposed in the metadata. Capgen shouldn't care. All it needs to know is how to access mytype_dat_t and what dependencies to compile.

Steps to Reproduce

See above. Should be reproducible with any of the capgen unit tests from develop

Additional Context

n/a

Output

See above

[climbfuji]

I think this is part of a bigger issue.

capgen should only care about (and parse the Fortran code fore) the components of a DDT if there is registered metadata for these components. Sometimes, we just want to pass a DDT as it is and not know anything about what it contains.

[peverwhee]

#684

was made to fix this - perhaps this is a bug within that handling.

we could potentially reconsider #673

but we're doing what you're trying to do here in SIMA without issue (as long as the type is in a use statement)

[climbfuji]

Thanks for this! I agree that this should be working and that there must be a bug somewhere.