moves the registration TU out of the core library into the final targets

[astronomerdave]

Required to meet camera 2.0 design

One of the design requirements was that:

The shared core library contains no registration of its own, so composing it as a dependency never forces a choice, and the executable target alone determines which registration is linked.

The previous build violates this by appending ${INSTRUMENT_SOURCES} into INTERFACE_SOURCES, which becomes the controller library. So the shared library carries a registration, and with an instrument selected, the instrument's sources.

This moves ${INSTRUMENT_SOURCES} to the camerad executable and the camera_interface python module. Both call Interface::create(), so both need it, and each ends up with exactly one. No runtime behavior changes.

Verified with generic build, -DINSTRUMENT=hispec_tracking_camera, and -DBUILD_PYTHON_MODULE=ON. With hispec selected:

• libarchon.a — 0 hispec symbols, 0 Interface::create definitions; previously it carried all four instrument objects
• bin/camerad — 262 hispec symbols, 1 Interface::create
• open, load, power on, expose 1 against the emulator all return DONE, and a FITS file is written

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-09-24 14:57 UTC

[prkrtg]

By doing this change, I think it will compile the instrument sources twice
We can instead build specifically the interface factory <instrument_name>_interface_factory.cpp

set (INSTRUMENT_REGISTRATION ${INSTRUMENT_SOURCES})
list (FILTER INSTRUMENT_REGISTRATION INCLUDE REGEX "_interface_factory\\.cpp$")
list (FILTER INSTRUMENT_SOURCES EXCLUDE REGEX "_interface_factory\\.cpp$")

then you can do

add_executable(camerad
  ${CAMERAD_DIR}/camerad.cpp
  ${CAMERAD_DIR}/camera_server.cpp
  ${INSTRUMENT_REGISTRATION}
  )

[astronomerdave]

You're right, give me a moment

[astronomerdave]

@prkrtg implementation goes into an object library so it compiles once without landing back in the core library.