Jim said:
> Both TOOL and TARGET variables are automatically set internally as/where needed. They are not part of the documented interface.
> TOOL variables control what tools are run (among those that OpenCPI builds, like ocpigen), and are currently set /determined by the sourced opencpi-setup.sh.
> TARGET variables are set internally in some places when you are building or running (via ocpidev) and default to the TOOL variables if no target RCC platform is specified.
At least that's the way it's supposed​ to work. The currently broken use case is one that wasn't tested, i.e., a build outside the context of "install-opencpi.sh" or "ocpiadmin install ...". Those two contexts (which were​ tested) ensure that appropriate TARGET variables get set. In other words, it's entirely possible that cases exist where TARGET variables aren't getting set where they need to be. And as Jim said, the appropriate default​ is the TOOL variables.
So, "export OCPI_TARGET_DIR=$OCPI_TOOL_DIR" after sourcing "opencpi-setup.sh" is an appropriate workaround in this case.
I'm mentioning this because blindly changing "OCPI_TARGET_DIR" back to "OCPI_TOOL_DIR" in "application.mk" is almost certainly wrong. The correct fix (or at least a more correct fix) would be to follow the trail upstream and determine how "application.mk" is getting called without "OCPI_TARGET_DIR" getting set. There are probably multiple places where checking to see if "OCPI_TARGET_DIR" is set is doable: the trick is finding the best place, which would be at the highest possible level in the calling sequence so you don't have to do the check/set more than once.
Please do​ write this up as a bug, and kindly pay particular attention to the "how to reproduce" section because there's no guarantee the person who will end up working the issue is among the people participating in this discussion.
Respectfully,
--Bob
Received on Wed Apr 26 2023 - 15:53:54 CDT