Misfinding ELPA Headers from Globle Visible Directory

[yizeyi18]

Describe the bug

If ELPA is installed in any global visible directory and another ELPA(without simbolic link made) was specified through only ELPA_DIR or CMAKE_PREFIX_PATH, wrong elpa headers from the global visible one would be used.
That may cause link error for using non-exist symbol, if the header's version mismatch with the library. A typical situation is, one personal user installed libelpa-dev from apt, and providing a install from source with version newer than 2022.11.001.

Expected behavior

CMake should catch the command-line earlier than the global one.

To Reproduce

1. Make a old elpa include available in a global visible directory. It should have ELPA_API_VERSION < 20220501 as source/module_hsolver/genelpa/elpa_generic.hpp defined.
   e. g. install libelpa-dev from apt and /usr/include/elpa/elpa/elpa.h appears, with a version of 2021.11.001.
2. Try compile abacus with another new elpa. It should have ELPA_API_VERSION >= 20220501.
   e. g. cmake -DELPA_DIR=/home/yizeyi18/soft/elpa-2023.05.001-install
3. At link time, ld would throw a error saying symbol not found.

Environment

• OS: Ubuntu 22.04
• Compiler: gcc 13.2.0
• Dependencies: ELPA

Additional Context

Previously, ABACUS find ELPA headers through trying to find $DIR/include/elpa/elpa.h or $DIR/include/elpa/elpa/elpa.h for $DIR in CMAKE_PREFIX_PATH, ELPA_DIR then global visible dirs. For users manually made the simbolic link $ELPA_DIR/include/elpa-$VERSION -> $ELPA_DIR/include/elpa following the docs, this would work; if not, error occcurs.
#3478 changed the doc, provided another routine to find them, but made the old routine done first; if a user is lucky enough to both install ELPA from apt and source, this bug will encounter.

Currently define ELPA_INCLUDE_DIRS in the command line explicitly is a way to avoid this bug; a PR would fix this later.

Task list for Issue attackers (only for developers)

• Verify the issue is not a duplicate.
• Describe the bug.
• Steps to reproduce.
• Expected behavior.
• Error message.
• Environment details.
• Additional context.
• Assign a priority level (low, medium, high, urgent).
• Assign the issue to a team member.
• Label the issue with relevant tags.
• Identify possible related issues.
• Create a unit test or automated test to reproduce the bug (if applicable).
• Fix the bug.
• Test the fix.
• Update documentation (if necessary).
• Close the issue and inform the reporter (if applicable).

[WHUweiqingzhou]

@caic99,
do you have any comment?

[caic99]

@caic99, do you have any comment?

@WHUweiqingzhou LGTM - I believe @yizeyi18 will later submit a PR to fix this.

[yizeyi18]

A similar case is, if specified Libxc have NO cmake config but another global visible Libxc have, cmake would use the global visible one instead of the specified one.
The linked PR would also fix this, with some logic changed.