Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle duplicate eta_echo #351

Open
mathomp4 opened this issue Jun 18, 2024 · 4 comments
Open

How to handle duplicate eta_echo #351

mathomp4 opened this issue Jun 18, 2024 · 4 comments
Assignees
Labels
question Further information is requested

Comments

@mathomp4
Copy link
Member

This is mainly a question for @rtodling (but maybe @tclune has some thoughts).

In this repo we define an eta_echo.x target which builds, unsurprisingly, eta_echo.x. This is fine for GEOSgcm, GEOSadas, etc.

But in my testing of JEDI-GEOS with jedi_bundle, an issue occurs because GSIbec also defines an eta_echo.x target. (Actually it defines it ... twice?)

The issue here is that when you do the full jedi_bundle build, it sees the target twice and CMake does not allow that.

In my testing, what I've done for now is, in my GEOSgcm spack-stack 1.7 builds, I change the name of the target here to eta_echo.GEOS.x.

But, we need a more "permanent" solution such that we don't need to alter GEOSgcm in the future.

So, I suppose for @rtodling what would be your preferred fix? We could change the target here in GMAO_Shared or we could change the target in GSIbec. I just don't know which is considered the more "canonical" eta_echo.x. I suppose if this code is used in operations, we'd want to keep the one in GMAO_Shared (aka GEOSadas) the same name so that scripts don't need to change.

But, if the one in GSIbec is more important, then maybe changing here is a simpler road?

@mathomp4 mathomp4 added the question Further information is requested label Jun 18, 2024
@tclune
Copy link
Collaborator

tclune commented Jun 18, 2024

I almost wonder if one needs to consider a namespace protection on executables (and libraries and includes) for precisely this situation. I'm sure we could make it optional so that GEOS users would see the old name but JEDI users would see something like GEOS_eta_echo.x (Similar to matt's change but putting it in front to be a true namespace indicator.)

Seems like other people must have this issue in complicated stacks.

@tclune
Copy link
Collaborator

tclune commented Jun 18, 2024

Sorry - not fully awake.

The CMake approach should have a completely separate install of GEOS. It gets its own /bin, /lib, etc. The mistake is presumably trying to use as a single unified project rather than using cmake find_package?

@mathomp4
Copy link
Member Author

I think the issue is that eta_echo.x is in our GEOSgcm-targets.cmake file when we do an install. So, it is an IMPORTED target that gets picked up by find_package(GEOSgcm)? I'm not sure.

Once I button down my jedi_bundle stuff, I'll do a v11.6.0 test and not change that target and see if things are better. Maybe the other changes I've had to do have "fixed" this?

@tclune
Copy link
Collaborator

tclune commented Jun 18, 2024

OK - just wanted to be clear that it is the target vs the name of the executable. Am still looking for how other complex projects deal with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants