Enable External Backend Integration

[anpaz]

Required prerequisites

• Search the issue tracker to check if your feature has already been mentioned or rejected in other issues.

Describe the feature

Summary

We want CUDA-Q to support backend integrations that are developed, built, and distributed outside the main CUDA-Q repository. This would allow hardware providers, research projects, and compiler/runtime extensions to integrate with CUDA-Q without requiring their target configuration, runtime libraries, or backend-specific assets to be copied into the CUDA-Q installation tree.

Motivation

Today, adding a new backend effectively requires treating it as part of the CUDA-Q distribution. That makes experimentation and third-party backend development harder than necessary, especially for backends that evolve independently or depend on additional packages, architecture descriptions, compiler extensions, or runtime components.

External backend integration would make CUDA-Q more extensible by allowing backend packages to provide their own target metadata, runtime support, optional architecture descriptions, and backend-specific execution behavior while still appearing to users as normal CUDA-Q targets.

Proposed Functionality

CUDA-Q should define a supported backend package model where an external package can:

• Advertise one or more CUDA-Q targets.
• Provide the target configuration needed by CUDA-Q.
• Provide any backend-specific runtime library required to execute or submit jobs.
• Register any compiler/runtime extensions needed by that backend.
• Be discovered by CUDA-Q at runtime without modifying the CUDA-Q install tree.

From the user’s perspective, an external backend should behave like a built-in target:

import cudaq

cudaq.set_target("my-backend", ...)
result = cudaq.sample(kernel, shots_count=1000)

The integration should be based on a stable backend contract rather than one-off special cases. A backend package should be able to provide its configuration, runtime assets, and optional compiler hooks in a self-contained way. CUDA-Q should discover these packages, make their targets available through the normal target-selection APIs, and route compilation/execution through the backend-provided capabilities.

Non-Goals

This item does not propose upstreaming any specific backend implementation.

Success Criteria

• External backends can be installed separately from CUDA-Q.
• CUDA-Q can discover those backends automatically or through a documented configuration mechanism.
• External targets appear through the normal CUDA-Q target APIs.
• Backend packages can provide their own target configuration and runtime assets.

[schweitzpgi]

Semi-related #4637 which started to add a way to add external subprojects to the CUDA-Q build.