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

Motivation for this project? #41

Open
windelbouwman opened this issue May 30, 2022 · 1 comment
Open

Motivation for this project? #41

windelbouwman opened this issue May 30, 2022 · 1 comment

Comments

@windelbouwman
Copy link

Hi,

I searched for the reason why this build system is layered on top of CMake, but was not able to find a section in the documentation on why this project was started, are there some features lacking in CMake, or are some macro's re-used over projects?

It would be good to have a small section in the readme explaining what the script in ecbuild add on top of CMake itself.

@tlmquintino
Copy link
Member

Hi @windelbouwman
Thanks you for your question(s).

This project started a decade ago (and was made public a few years later) to provide higher level functions to CMake, in order to build a whole lot of production code we have at ECMWF. Once your code started being made public, we also had to make ecbuild public because that code uses functions defined here.

So what is ecbuild for?
The first aim is to make CMake look more functional, with less boiler plate code. For example, defining a library with all dependencies and sources is a matter of a few lines.

The second aim is consistency. We use to build many components across a very complex software stack. Ensuring a few consistency rules becomes simpler if all packages use the same functions, define libraries in the same way, etc etc.

The third aim, very much a concern when we started, was to have a central code repo to provide some workarounds that CMake hadn't sorted at the time. For example Fortran support was very patchy, especially for intra package dependencies and interface generation. We cater for certain quirks in some exotic architectures (we mostly build in HPC systems, at the time there was no Cray support). Prior to CMake 3, we also catered for better for dependencies across multiple CMake projects, with automatic export, transitional dependencies, etc. Since CMake 3 many of these issues have been addressed, but some still remain (only a few).

Your question on the script is very well posed. The script is simply convenience, it does not bring much beyond shorter command line options. We see some usage of it, but in many of our automated systems, we actually just call cmake directly.
Feel free to ignore the bin/ecbuild script.

Does this explanation help?

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