_get_dpc_deps in dev/bazel/dal.bzl builds a DPC++ target's dependencies by appending _dpc to every entry of dal_deps. For tests and examples, dal_deps comes from _test_link_mode_deps, which is a select over the link mode:
def _test_link_mode_deps(dal_deps, use_onedal_release_libs=True):
return _select({
"@config//:test_link_mode_dev": dal_deps,
"@config//:test_link_mode_release_static": ["@onedal_release//:onedal_static"],
"@config//:test_link_mode_release_dynamic": ["@onedal_release//:onedal_dynamic"],
})
So a DPC++ target in release_static mode asks for @onedal_release//:onedal_static_dpc, and neither dev/bazel/deps/onedal.tpl.BUILD nor dev/bazel/deps/onedal_win.tpl.BUILD declares such a target. Measured on Linux, main, against a Bazel-built release:
$ bazel cquery 'filter(":onedal_", deps(//examples/oneapi/dpc:_basic_statistics_dense_batch_dpc))' \
--test_link_mode=release_static
ERROR: .../external/+onedal_repo+onedal_release/BUILD: no such target
'@@+onedal_repo+onedal_release//:onedal_static_dpc': target 'onedal_static_dpc' not declared
... and referenced by '//examples/oneapi/dpc:_basic_statistics_dense_batch_dpc'
ERROR: Analysis of target '//examples/oneapi/dpc:_basic_statistics_dense_batch_dpc' failed
The same query in release_dynamic mode resolves, because onedal_dynamic_dpc happens to exist:
$ bazel cquery 'filter(":onedal_(dynamic|static)", deps(//examples/oneapi/dpc:_basic_statistics_dense_batch_dpc))' \
--test_link_mode=release_dynamic
@onedal_release//:onedal_dynamic_dpc (431669a)
CI does not notice because no job builds a DPC++ test or example in a release link mode. The release-mode example steps in .ci/pipeline/ci.yml are //examples/daal/cpp:all and //examples/oneapi/cpp:all, and neither package contains a _dpc cc_test/cc_binary target — the only dpc-named entries there are the example_util_dpc header module. //examples/oneapi/dpc:all (94 targets) is never built in release_static or release_dynamic by any pipeline.
Two ways out, and I have no opinion strong enough to pick without a maintainer:
- Declare the missing release targets (
onedal_static_dpc, and on Windows the DPC import library/DLL in onedal_repo first) so that DPC++ tests and examples can genuinely link against a release.
- Make the release-mode dependency selection non-DPC-aware, i.e. do not
_dpc-mangle labels that come from _test_link_mode_deps, so DPC++ targets in release modes link the host release libraries deliberately rather than by accident.
Either way it would be worth adding a //examples/oneapi/dpc:all --test_link_mode=release_dynamic step, otherwise the configuration stays untested whichever fix lands.
Found while reviewing feedback on #3790, which removes the Windows onedal_dynamic_dpc stub; that target is unreachable in every configuration CI exercises, and this issue is the reason the asymmetry existed in the first place.
_get_dpc_depsindev/bazel/dal.bzlbuilds a DPC++ target's dependencies by appending_dpcto every entry ofdal_deps. For tests and examples,dal_depscomes from_test_link_mode_deps, which is aselectover the link mode:So a DPC++ target in
release_staticmode asks for@onedal_release//:onedal_static_dpc, and neitherdev/bazel/deps/onedal.tpl.BUILDnordev/bazel/deps/onedal_win.tpl.BUILDdeclares such a target. Measured on Linux,main, against a Bazel-built release:The same query in
release_dynamicmode resolves, becauseonedal_dynamic_dpchappens to exist:CI does not notice because no job builds a DPC++ test or example in a release link mode. The release-mode example steps in
.ci/pipeline/ci.ymlare//examples/daal/cpp:alland//examples/oneapi/cpp:all, and neither package contains a_dpccc_test/cc_binarytarget — the onlydpc-named entries there are theexample_util_dpcheader module.//examples/oneapi/dpc:all(94 targets) is never built inrelease_staticorrelease_dynamicby any pipeline.Two ways out, and I have no opinion strong enough to pick without a maintainer:
onedal_static_dpc, and on Windows the DPC import library/DLL inonedal_repofirst) so that DPC++ tests and examples can genuinely link against a release._dpc-mangle labels that come from_test_link_mode_deps, so DPC++ targets in release modes link the host release libraries deliberately rather than by accident.Either way it would be worth adding a
//examples/oneapi/dpc:all --test_link_mode=release_dynamicstep, otherwise the configuration stays untested whichever fix lands.Found while reviewing feedback on #3790, which removes the Windows
onedal_dynamic_dpcstub; that target is unreachable in every configuration CI exercises, and this issue is the reason the asymmetry existed in the first place.