You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The prerequisite repos and packages should be downloaded and built as part of the prereq build and install script and not part of the tpls/ directory tree. These files are not required by any other backend. The current integration is downloading these repos and their submodules and trying (unsuccessfully in general) to configure and build them as a cmake configuration step at project build time. Since not every build will want (or can) build the Braket backend this latter approach doesn't really work.
See PR 2362 for an initial draft that removes the submodule and adds a CMake variable to allow the inclusion of the Braket backend under user control. This PR is incomplete: the CI will require changes to the build scripts to enable the Braket backend for testing, etc. Also the tests specifically tailored for the Braket backend must be updated to use REQUIRES: bracket or some such configuration setting for developer builds and builds in other ad hoc environments.
Looking through the cmake files, some of the targets are opt-in and some of them are hardcoded to always get built. We should be more rigorous here and have the default backend built by default and the other backends selectable via cmake command line variables. This structure will provide the greatest portability for tool builders and end-users.
The text was updated successfully, but these errors were encountered:
With the Braket backend:
The prerequisite repos and packages should be downloaded and built as part of the prereq build and install script and not part of the
tpls/
directory tree. These files are not required by any other backend. The current integration is downloading these repos and their submodules and trying (unsuccessfully in general) to configure and build them as a cmake configuration step at project build time. Since not every build will want (or can) build the Braket backend this latter approach doesn't really work.See PR 2362 for an initial draft that removes the submodule and adds a CMake variable to allow the inclusion of the Braket backend under user control. This PR is incomplete: the CI will require changes to the build scripts to enable the Braket backend for testing, etc. Also the tests specifically tailored for the Braket backend must be updated to use
REQUIRES: bracket
or some such configuration setting for developer builds and builds in other ad hoc environments.Looking through the cmake files, some of the targets are opt-in and some of them are hardcoded to always get built. We should be more rigorous here and have the default backend built by default and the other backends selectable via cmake command line variables. This structure will provide the greatest portability for tool builders and end-users.
The text was updated successfully, but these errors were encountered: