Reduce the number of environment variables

[diegoferigo]

Even if at the time of writing gazebosim/gz-sim#172 has not been merged, we should keep an eye on it since it could allow us to reduce the number of environment variables to export.

[traversaro]

I never opened a issue upstream to propose that, but I personally think that it would be ideal to have a single IGN_PREFIX_PATH env variable, similary to how CMake have a single CMAKE_PREFIX_PATH variable even if it also have CMAKE_PROGRAM_PATH, CMAKE_LIBRARY_PATH, etc etc.

[diegoferigo]

Do you mean a single unified env variable that could be used for everything (worlds, models, meshes, plugins, physics plugins, rendering plugins, etc)? In gazebosim/gz-sim#172 it seems that they are unifying at least all the SDF resources under IGN_GAZEBO_RESOURCE_PATH, that is already a step forward.

[traversaro]

Do you mean a single unified env variable that could be used for everything (worlds, models, meshes, plugins, physics plugins, rendering plugins, etc)?

Yes.

In ignitionrobotics/ign-gazebo#172 it seems that they are unifying at least all the SDF resources under IGN_GAZEBO_RESOURCE_PATH, that is already a step forward.

Definitely a step forward.

[chapulina]

I never opened a issue upstream to propose that

Just an extra reference, you've brought this up on this other PR 😉. One of the reasons for keeping some paths separate is for cases when we want to list the entire content of some paths, like how all plugins in IGN_GUI_PLUGIN_PATH end up on the menu. But we're trying to condense them as much as possible.

[traversaro]

I never opened a issue upstream to propose that

Just an extra reference, you've brought this up on this other PR 😉.

Thanks, I had completely forgot about it.

One of the reasons for keeping some paths separate is for cases when we want to list the entire content of some paths, like how all plugins in IGN_GUI_PLUGIN_PATH end up on the menu. But we're trying to condense them as much as possible.

Yes, but to clarify the proposal (at least on CMake) the unified variable CMAKE_PREFIX_PATH exists and is defined as:

Semicolon-separated list of directories specifying installation prefixes to be searched by the find_package(), find_program(), find_library(), find_file(), and find_path() commands.
But then there are also individual env variables for each call, if users need more granularity:

• CMAKE_PROGRAM_PATH for find_program
• CMAKE_LIBRARY_PATH for find_library
• CMAKE_INCLUDE_PATH for find_file and find_path .

Then clearly there is the usual trade-off between flexibility and simplicity, so in any case it is debatable if the unified env variable would be worth it.