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
Leave the situation like this, where the default value of RENDER_ENGINE_VALUES reflect the official OpenRobotics CI configuration. In that case however it would be great if the test could explicitly fail on missing engine, so that it is clear that the "user" (tipically someone packaging the library) needs to set the RENDER_ENGINE_VALUES env variable value.
Implementation suggestion
If the feature is welcome, I can look in the suggestion.
it would be great if the test could explicitly fail on missing engine, so that it is clear that the "user" (tipically someone packaging the library) needs to set the RENDER_ENGINE_VALUES env variable value.
ok yeah that sounds good to me.
ctest would actually test just and only the enabled engines
One comment: we currently don't have a way to run ogre and ogre2 tests one after another because of symbol collision. So one thing to keep in mind is that these two engines can not be enabled at the same time.
Desired behavior
I would like that after a configuration of ign-rendering on a given system,
ctest
would actually test just and only the enabled engines. At the moment this is not the case, as the list of tested engines is hardcoded in https://github.com/ignitionrobotics/ign-rendering/blob/50e1e5fa936176a570b6b4cccbbe081334af6057/test/test_config.h.in#L14Alternatives considered
Leave the situation like this, where the default value of RENDER_ENGINE_VALUES reflect the official OpenRobotics CI configuration. In that case however it would be great if the test could explicitly fail on missing engine, so that it is clear that the "user" (tipically someone packaging the library) needs to set the
RENDER_ENGINE_VALUES
env variable value.Implementation suggestion
If the feature is welcome, I can look in the suggestion.
Additional context
See conda-forge/libignition-rendering4-feedstock#19 (comment) for the context in which this issue was detected.
The text was updated successfully, but these errors were encountered: