Allow per-library fallback LAL data path for XLALFileResolvePathLong()
Description
Detailed description of the changes, why they are being made, etc... Also indicate appropriate tickets and tests that have been run to determine that the changes work as intended and do not introduce other problems.
API Changes and Justification
-
XLALFileResolvePathLong()
replacesfallbackdir
withfallbackpath
- May contain either absolute or relative (to
liblalsupport.so
) paths
- May contain either absolute or relative (to
-
LALSUITE_WITH_FALLBACK_DATA_PATH
(replacesLAL_WITH_DATA_PATH
) definesLAL_FALLBACK_DATA_PATH
to fallback LAL data path- Defaults to
$(pkgdatadir)
, same as forfallbackdir
argument
- Defaults to
- New macro
XLAL_FILE_RESOLVE_PATH()
passesLAL_FALLBACK_DATA_PATH
toXLALFileResolvePathLong()
, so each library gets its own fallback path- Not designed to be used outside of LALSuite; libraries implement their
own functions (e.g.
XLALReadEphemerisFile()
,XLALSimReadDataFileOpen()
) which callXLAL_FILE_RESOLVE_PATH()
internally
- Not designed to be used outside of LALSuite; libraries implement their
own functions (e.g.
- Non-inline
XLALFileResolvePath()
andXLALPulsarFileResolvePath()
wrappers kept to avoid breaking ABI -
.gitlab-ci.yml
: add finding data files test tolalpulsar_longtests
Backwards Compatible Changes
-
This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions -
This change adds new classes/functions/structs/types to a public C header file or Python module
Backwards Incompatible Changes
-
This change modifies an existing class/function/struct/type definition in a public C header file or Python module -
This change removes an existing class/function/struct/type from a public C header file or Python module
If any of the Backwards Incompatible check boxes are ticked please provide a justification why this change is necessary and why it needs to be done in a backwards incompatible way.
Review Status
n/a p
Edited by Karl Wette