Currently, libastcanopy filter out the filenames that are not in list of files_to_retain by full path match. This is problematic because often times the path from which the header file is searched could be a symlink. And while clangToolings path normalization strategy is unknown, it directs the source to the declaration with the un-symlinked path, which differs from the path passed in via files_to_retain.
For example, curandStateMtgp32 is defined in header curand_mtgp32.h, which locates under /usr/local/cuda/include. However clangTooling will un-symlink this path to /usr/local/cuda-12.4/include - which is the same path to the former. But curandStateMtgp32 will get ignored because ast_canopy uses a full-path match.
An ideal solution is to take a more flexible path matching strategy that's based on the base name. The easiest way is to match the path as long as the path contains the base name. The only concern is to this is that conflicting files to the same path is introduced. (Though arguing to this, this should be an issue of misconfigured include search paths to the compiler engine, not the issue of path matching).
Currently, libastcanopy filter out the filenames that are not in list of
files_to_retain
by full path match. This is problematic because often times the path from which the header file is searched could be a symlink. And while clangToolings path normalization strategy is unknown, it directs the source to the declaration with the un-symlinked path, which differs from the path passed in viafiles_to_retain
.For example,
curandStateMtgp32
is defined in headercurand_mtgp32.h
, which locates under/usr/local/cuda/include
. However clangTooling will un-symlink this path to/usr/local/cuda-12.4/include
- which is the same path to the former. ButcurandStateMtgp32
will get ignored because ast_canopy uses a full-path match.An ideal solution is to take a more flexible path matching strategy that's based on the base name. The easiest way is to match the path as long as the path contains the base name. The only concern is to this is that conflicting files to the same path is introduced. (Though arguing to this, this should be an issue of misconfigured include search paths to the compiler engine, not the issue of path matching).