Install ev-cli locally and depend on templates files for generation

[hikinggrass]

Describe your changes

Issue ticket number and link

Checklist before requesting a review

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• I read the contribution documentation and made sure that my changes meet its requirements

[a-w50]

Hi,

in general, the implementation as of now should work.
I see an issue with that implementation details of ev-cli are exposed to the CMakeFiles.txt (i.e. template filenames are hardcoded into the depends). This could be easily mitigated by adding an argument to ev-cli like ev-cli interface get-templates etc. This way ev-cli can tell you directly what it uses (hence you also won't need the get-package-location script anymore). So instead of running the new script, you run ev-cli and get the corresponding files as a return value and pass these directly into the depends.
Another thing is the usage of set/get_property(GLOBAL ... ), if possible, try to add these variables to a specific target, this gives you some scoping and depending on the use case you can easily retrieve it via an generator expression:
"$<TARGET_PROPERTY:target_name,PROPERTY_NAME>"

[a-w50]

Great work!
I would suggest to change PATHS to HINTS (see below). Furthermore, I think the main CMakeLists.txt needs to depend on everest-cmake 0.5. The additional python script could now be removed again, right?

[a-w50]

As this is a function, I wouldn't prefix all the variables with EV_CLI in order to make it more readable

[a-w50]

As discussed offline

[hikinggrass]

TODO: update the git_tag to a tag before merge into main

[andistorm]

In general it is a nice feature to be able to define the used everest-cmake version.

Proposal:
Could we add everest-cmake to the dependencies.yaml and then check it out with edm. I think there is currently not that kind of command, but I imagine having here one line (kind of)

edm single-checkout everest-cmake --workspace-config everest-core/dependencies.yaml

This way it would be more visible where to set everest-cmake version

[andistorm]

Alternativley we could add another file like ci-workspace.yaml and add it there since this version pinning is mainly for ci

[a-w50]

• note sure if adding everest-cmake to dependencies.yaml will work in the current implementation as the cmake specific edm function evc_setup_edm is defined in everest-cmake and you'll get an chicken-egg problem
• concerning ci-workspace.yaml, I wouldn't try to add additional coupling of the ci to edm. First we should try to solve the problem, that the repo specific Dockerfile isn't used.

[andistorm]

note sure if adding everest-cmake to dependencies.yaml will work in the current implementation

It should work since when building with cmake it could ignore this one dependency and use the provided everest-cmake installation. But when running in ci edm can read this dependency from dependencies.yaml.

I agree that it could be confusing defining everest-cmake in dependencies.yaml without using it in the cmake build. This could improved by adding in line comment and set cmake_condition to OFF

concerning ci-workspace.yaml, I wouldn't try to add additional coupling of the ci to edm.

Why not using edm in ci? It is the EVerest dependency manager which is used during build, but also as dev tool to manage the dev workspace.

The advantage I see or my motivation is to have a transparent/visible way of defining dependencies. Doing it in compile.sh is hidden in my feeling.

Moving it into the Dockerfile without using edm for it would also be an option.

First we should try to solve the problem, that the repo specific Dockerfile isn't used.

I am not aware of this issue, do you have an example or a log file?

[andistorm]

I am not aware of this issue, do you have an example or a log file?

Sorry my bad. I remember, we deactivated this for everest-core since we have this issue with running this in PRs

[a-w50]

It might work by accident, but probably with no real well defined behavior. I would not rely on that.
Concerning the coupling in the ci: I didn't mean that we should not run edm in the ci as it is run locally - but I wouldn't add an extra dependency overwrite file for the ci (as both the local build and the ci build should be similar).
Using `find_package(everest-cmake X.Y.Z) we can already express, that we need a newer version.

I totally agree, that moving it to the compile.sh was a hack to get the ci build, but it should not be committed this way. Having it in the Dockerfile, should be the way to go - but that doesn't work currently.