Drop the FPP JSON model and adopt the FprimePython CMake hook

CMakeLists.txt

@@ -11,21 +11,10 @@ project(FprimePythonReference C CXX)
 # F' Core Setup
 # This includes all of the F prime core components, and imports the make-system.
 ###
-set(FPRIME_ENABLE_JSON_MODEL_GENERATION ON)
 include("${CMAKE_CURRENT_LIST_DIR}/lib/fprime/cmake/FPrime.cmake")
 
-# Register fprime_python build target
-if (NOT DEFINED FPRIME_SUB_BUILD_TARGETS)
-    # FPP locations must come at the front of the list, then build
-    set(CMAKE_POSITION_INDEPENDENT_CODE ON)
-    set(PYBIND11_FINDPYTHON ON)
-    # Locate the pip-installed pybind11 CMake package via the interpreter
-    execute_process(COMMAND python3 -m pybind11 --cmakedir
-            OUTPUT_VARIABLE PYBIND11_CMAKEDIR OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_QUIET)
-    find_package(pybind11 CONFIG REQUIRED PATHS "${PYBIND11_CMAKEDIR}" "$ENV{VIRTUAL_ENV}/lib/*/site-packages/")
-    link_libraries("pybind11::module" "pybind11::headers")
-    register_fprime_target(target/fprime_python)
-endif()
+# Set up the Python bindings: pybind11, position independent code, and the fprime_python build target
+include(FprimePython)
 
 
 # NOTE: register custom targets between these two lines

FprimePythonReference/ReferenceDeployment/CMakeLists.txt

@@ -18,11 +18,3 @@ register_fprime_deployment(
     DEPENDS
         ${FPRIME_CURRENT_MODULE}_Top
 )
-
-# The conventional C++ deployment executable links component libraries containing pybind11
-# code, so it must resolve the Python C API at link time. The fprime_py extension module
-# does not need this: it receives these symbols from the hosting interpreter.
-# Guarded: pybind11 is not located during fprime sub-builds
-if (TARGET pybind11::embed)
-    target_link_libraries("${FPRIME_CURRENT_MODULE}" PRIVATE pybind11::embed)
-endif()

FprimePythonReference/ReferenceDeployment/README.md

@@ -4,42 +4,9 @@ This deployment was auto-generated by the F' utility tool.
 
 ## Building and Running the ReferenceDeployment Application
 
-In order to build the ReferenceDeployment application, or any other F´ application, we first need to generate a build directory. This can be done with the following commands:
-
-```
-cd ReferenceDeployment
-fprime-util generate
-```
-
-The next step is to build the ReferenceDeployment application's code.
-```
-fprime-util build
-```
-
-## Running the application and F' GDS
-
-The following command will spin up the F' GDS as well as run the application binary and the components necessary for the GDS and application to communicate.
-
-```
-cd ReferenceDeployment
-fprime-gds
-```
-
-
-To run the ground system without starting the ReferenceDeployment app:
-```
-
-cd ReferenceDeployment
-fprime-gds --no-app
-```
-
-The application binary may then be run independently from the created 'bin' directory.
-
-```
-cd ReferenceDeployment/build-artifacts/<platform>/bin/
-./ReferenceDeployment -a 127.0.0.1 -p 50000
-```
+ReferenceDeployment is a Python deployment: its topology is annotated `@ fprime-python` and it is started from Python by `fsw_main.py` rather than from a C++ executable. `Main.cpp` is a stub that only satisfies the build of the deployment target.
 
+Build and run it from the root of the project, as described in the [project README](../../README.md).
 
 ## This deployment uses F' **core subtopologies** for a modular, reusable architecture:
 

README.md

@@ -35,24 +35,38 @@ fprime-util generate
 fprime-util build
 ```
 
-> [!CAUTION]
-> The build for `fprime-python` projects will be much slower as it is autocoding more items, as well as running complete model exporting with `fpp-to-json`.
+> [!NOTE]
+> The build for `fprime-python` projects is slower than a C++ build as it also autocodes and compiles the Python bindings.
+
+The build installs the `fprime_py` extension module and every Python file of the deployment to `build-artifacts/python`. Python files are reinstalled by every `fprime-util build`.
 
 ## Running
 
-To run the project, first run the GDS in the root of the project:
+The flight software runs inside a Python interpreter, so it is started separately from the GDS. The reference's communication component, `PythonTcpCom`, listens for a TCP connection; the GDS must therefore connect as a client.
+
+First, run the GDS in the root of the project:
 
 ```bash
 . fprime-venv/bin/activate
-fprime-gds
+fprime-gds --ip-client
 ```
 
 > [!NOTE]
-> This automatically starts the GDS without running the executable.
+> `fprime-gds.yml` sets `--no-app`, which starts the GDS without running an executable.
 
-Next, run Python with the bindings installed:
+Next, in a second terminal, run the flight software with the same Python that built it:
 
 ```bash
+. fprime-venv/bin/activate
 python3 build-artifacts/python/fsw_main.py
 ```
 
+`fprime-python-runner` does the same from any directory of the project. `--hostname` and `--port` set the address `PythonTcpCom` listens on (default `127.0.0.1:50000`); give the GDS the matching `--ip-address` and `--ip-port`.
+
+## Testing
+
+With the GDS and the flight software running, run the integration tests from the root of the project:
+
+```bash
+pytest test/int --dictionary build-artifacts/*/FprimePythonReference_ReferenceDeployment/dict/ReferenceDeploymentTopologyDictionary.json
+```

requirements.txt

@@ -6,4 +6,3 @@
 ./lib/fprime-python/
 pybind11==3.0.2
 opencv-python==4.12.0.88
-fprime-python-model>=3.3.0a2