Now finds libaec with find_package

[Ozaq]

Description

Now finds libaec from libaec-config.cmake

This is in preparation to move libaec to be a source dependency in
cxx-dependencies where we will be providing libaec 1.1.4.

This is also part of bump of libaec to 1.0.6 across the whole C++ stack.
With 1.0.6 libaec introduced cmae config files that replace FindModules.
Unfortunately the cmake config file for libaec 1.0.6 to 1.1.3 do not
work correctly if libaec is not installed system wide in combination
with a system wide installed version of libaec. The bug is that the
configuration file just picks up the first libaec.h file and the first
libaec.so. Which in this combination will point to the system wide
installed version.

This can (and is addressed in this PR) by hinting cmake to the correct
location of the loaded aec module on ATOS.

When using CMAKE_PREFIX_PATH this is not an issue because those paths
will be preferred for the resolution.

Libaec 1.1.4 fixes this issue.

Contributor Declaration

By opening this pull request, I affirm the following:

• All authors agree to the Contributor License Agreement.
• The code follows the project's coding standards.
• I have performed self-review and added comments where needed.
• I have added or updated tests to verify that my changes are effective and functional.
• I have run all existing tests and confirmed they pass.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.74%. Comparing base (448bd32) to head (b899032).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop      #73   +/-   ##
========================================
  Coverage    77.74%   77.74%           
========================================
  Files           97       97           
  Lines         4933     4933           
  Branches       444      444           
========================================
  Hits          3835     3835           
  Misses        1098     1098           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ChrisspyB]

I would quite like to continue failing at config time if the aec version is too old. Unless there has been an update to ecbuild, "VERSION 1.1.1 REQUIRED" has proven insufficient to ensure this.

[ChrisspyB]

The correct solution would be for ecbuild to properly fail if it picks it only picks up an aec older than 1.1.1. I believe the issue may be due to older aec's not having a discernable version number, so ecbuild fails to validate the version and keeps marching on...

[Ozaq]

Please notice that we are not using the old FindAEC.cmake here any longer, but we are searching for a dependency 'libaec'. Libaec starting with 1.0.6 supplies version information in its libaec-config.cmake (I checked all distros we use). Further this is now the minimum accepted version across the stack. So this should error out reliably if any other ecbuild_find_package has picked up an earlier libaec. Internally this falls back to a find_package in config mode with modern targets and version numbers.

[ChrisspyB]

Is it going to be compulsory to build eckit/eccodes with aec 1.1.1+?

[ChrisspyB]

afaik, it is currently not compulsory to build those libraries with aec at all.

[Ozaq]

No this comment is about

unset(AEC_INCLUDE_DIRS CACHE)
unset(AEC_LIBRARIES CACHE)

still being in the code, this was left in for the transitionary period when eckit did not yet remove the use of FindAEC.cmake

The minimum eckit version should be hiked to the next version (current develop) to ensure eckit/eccodes/gribjump use all ecbuild_find_pacakge(libaec) (aka use libaec-config.cmake instead of FindAEC.cmake)

[Ozaq]

Dropping this PR, this needs to go into the full on cxx-migration