Python build system fixes
Description
Fix various things in the Python build system.
- Stubs for Python scripts created by
gnuscripts/lalsuite_python.am
- These stubs are created when LALSuite is not installed into the same prefix as Python, e.g. a "traditional" (non-virtual environment) local LALSuite build. The stubs set up
PYTHONPATH
correctly and then execute the actual Python script. When LALSuite is installed into the same prefix as Python (e.g. a system package install, or virtual environment), no stubs are created, and instead the actual Python scripts are made into executables. - The detection of whether or not LALSuite is installed into the same prefix as Python was inadvertently broken by !2338 (merged) and as a result the stubs were no longer created when required. This also affected the wheels (which require the stubs) which !2356 (merged) intended to address.
- With this MR
gnuscripts/lalsuite_python.am
now correctly predicts when the stubs are required. As a result the fix from !2356 (merged) should no longer be required and is reverted. - The stubs are now also written in Python rather than Bash.
- These stubs are created when LALSuite is not installed into the same prefix as Python, e.g. a "traditional" (non-virtual environment) local LALSuite build. The stubs set up
- Require shebang placeholder line in Python scripts
- All Python scripts which are installed as executables must have
##python
as their first line. This line may be replaced upon installation with a proper#!...
shebang line, depending on how the script is installed (i.e. via a stub, or as an executable script). - The reason for requiring
##python
as the first line in all Python scripts is to keep line numbers consistent between the source script in Git and the installed executable version. Currently, an installed Python script will have line numbers off by one from its source script in Git, which could be confusing when debugging error messages.
- All Python scripts which are installed as executables must have
- SWIG configuration
- During configuration of the
CPPFLAGS
used to build the SWIG Python wrappers, include the NumPy-I
flags before any system-I
flags. This ensures any local (e.g. virtual environment) NumPy is picked up first. This is important if e.g. you have NumPy 2.x in a virtual environment, but the system version is NumPy 1.x.
- During configuration of the
API Changes and Justification
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
Review Status
n/a