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

Compilation with cmake/hirlam #41

Open
AlexandreMary opened this issue Nov 21, 2024 · 2 comments
Open

Compilation with cmake/hirlam #41

AlexandreMary opened this issue Nov 21, 2024 · 2 comments
Assignees

Comments

@AlexandreMary
Copy link
Contributor

AlexandreMary commented Nov 21, 2024

Introduction of an additional "flavour" of compilation, being with cmake/hirlam instead of gmkpack.

Facing some issues during Davai WW3:

  • cmake/hirlam not able to start from an IAL git ref, because of the tight binding between cmake/hirlam and HarmonieCSC (... tbc ...)
  • Davai could alternatively (say, in a different usecase/-u) start from an HarmonieCSC git ref
  • Preliminary step Dissociate git2pack & pack2bin into 2 jobs #31 is achieved, should make it easier.

Conclusion of the Davai WW3:

  • using cmake/hirlam to compile IAL binaries require rearranging of cmake/hirlam, for now too bound to teh HarmonieCSC structure
  • we could have a separate usecase of Davai, starting from a HarmonieCSC git ref, then running with it a subset of tasks. However this requires the user to have access to Hirlam repositories. And the cmake/hirlam generated binaries require specific environments to be ran (otherwise some linked libraries are missing), which for now prevents from running Davai tests with them.
@AlexandreMary
Copy link
Contributor Author

@roelstappers can you describe the difficulties you faced and any relevant piece of information to that regard ?

@roelstappers
Copy link

roelstappers commented Nov 21, 2024

The issue is indeed the tight binding between Hirlam scripts and the cmake. We could hack something together but it is not so clear what we achieve and what we are even testing in that case. The solution will also be only working for members of the hirlam github because of the need for our Auxlibs repo. Best would be that we first make the compilation in HarmonieCSC a bit more portable (e.g. treat the Auxlibs as normal external project like we do for field_api etc. Our use of git submodules to handle these dependencies is bad for portability. Then I think we would also need to treat IAL itself as an external project in cmake. So for now I think the easiest solution would be to make sure that our Harmonie MASTERODB becomes portable, i.e. doesn't rely on LD_LIBRRARY_PATH so we can replace the gmkpack MASTERODB from Davai with our MASTERODB in the Davai runs to test the cmake builds

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

No branches or pull requests

2 participants