Feature check is prohibiting calling ml-api from ml-train api side which is at another repo. about api HOT 5 CLOSED

You may keep using _ml_set_feature_check for unit-test. You are not doing integration test; thus, you are not supposed to test other operating system (Tizen) features with your unit tests.

_ml_set_feature_check is not a workaround for unit-test, although you are NOT supposed to use it in integration test or tests in an actual target devices.

Comments on the "Long term solutions"
1: no. you don't need to do so.
2: yes, for Tizen, you need to do so for integration tests (there are such tests in dashboard.tizen.org, conducted when you do SR). But, keep in mind that this is a different and independent test set and you should keep the current "conventional" unit tests.
3: no. you are going to test tests, not the core implementation.
4: no. you are over-engineering. turning on/off feature checks is sufficient.

If you want to test feature-checks correctly, you need to add integration test cases (look at "ITC" of Tizen)

from api.

cibot: Thank you for posting issue #110. The person in charge will reply soon.

from api.

Pulling comment here @jaeyun-jung
nnstreamer/nntrainer#1712 (comment)

Need discussion later.
To run the unittests on gbs-build, we should block tizen-feature for ML API. Internally ml-api (api repository, nnstreamer only now) disables feature state while running unittests.
If nntrainer uses ml-common APIs (tensors-info and tensors-data), unittests in nntrainer always report failure because common ML API cannot check the feature state on gbs-build.

from api.

Cool, thanks for the comment!

As per comment, I guess nnstreamer/nntrainer#1715 is sufficient to close this issue :)

You may keep using _ml_set_feature_check for unit-test.

@jaeyun-jung could you once review nnstreamer/nntrainer#1715 for the completeness?

Thank you!

from api.

Resolved with nnstreamer/nntrainer#1715 :)

from api.