Using mepo for the clone task

[Dooruk]

Like we discussed during the meeting, we could benefit from using mepo for cloning which would provide better and consistent handle over the version/commit/tag management.

Most of this work is already done under:
https://github.com/GEOS-ESM/jedi_obsimul

Waiting on some PRs to go in:
JCSDA-internal/ioda-converters#1660

FYI @rtodling @ashiklom

[Dooruk]

I was talking with @metdyn today, he is familiar with building JEDI and mepo so perhaps he would some inside with this too.

[metdyn]

I have been thinking about this, and Matt wrote the CMakeList file for jedi_obsimul. We can work along the line.

[mathomp4]

So is the task just using mepo to clone jedi_bundle? Or also to then use CMake to build as well? If just cloning, that should be simple, we'd just need to know where to clone. Building is when it gets more fun.

I will say that, at present, mepo does not do parallel cloning like was introduced in #80 . I mean, I suppose it could (pending thoughts by @pchakraborty) but it hasn't really been a focus of mepo because of the nested nature of other GEOS repos. But if repos aren't nested, then, it should be possible...

The other thing is that mepo has no concept of "optional repos" which it looks like jedi_bundle currently has. Again, probably not impossible to implement, but would need to be thought on.

[Dooruk]

We can begin by cloning only. As far as I understand mepo can handle tags, branches and commit hashes is that correct? Is the problem defining interdependencies of a particular repo to the other repos?

The clone task also creates the CMakeList.txt file at the end by the way.

Parallel cloning is not necessary, there has been drop in number of JEDI repos so it became even less relevant now. I just add it since it was a simple change in the script.

I understand from your remarks in the past in terms of actually building the code one major block is the order of building (i.e., the build-order.yaml). Is that a missing capability in mepo? Or since you are able to build using mepo I'm assuming you already resolved that somehow with Cmake flags?

For reference for the others, I did write most of the current capabilities here: GEOS-ESM/jedi_obsimul#2

[mathomp4]

@Dooruk Yes. The "hard" part (once things are cloned) is the ExternalProject_Add bits:

ExternalProject_Add(
  ioda-converters
  SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/@ioda-converters
  CMAKE_ARGS
    -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_INSTALL_PREFIX}
)
ExternalProject_Add_StepDependencies(ioda-converters build oops)
ExternalProject_Add_StepDependencies(ioda-converters build ioda)

where this says ioda-converters depends on oops and ioda. There is no way to intuit this, but then you all here have a nice file that has the dependencies in a way (or at least an order).

[Dooruk]

Over the past few months there has been additional repos, ufo-data and ioda-data, in JEDI, I'm wondering if those changes helped with the dependency problems mentioned here? Or made it worse?