John Regehr <regehr@cs.utah.edu> writes:
I would probably lean towards feeding this kind of information to clang_delta
using an environment variable rather than pushing it through C-Reduce. How
does that strike people?
[Preafce: Form later emails, I get the impression that this discussion might be
moot, because the ultimate patch might not invoke `clang' at all. But
anyway....]
Well, I like the way we do things now, but perhaps that's not surprising, since
I implemented the way we do things now.
The point of burning things in is to keep the behavior of an installed C-Reduce
from changing, insofar as we can control that w/o actually installing our own
copies of the tools. E.g., if the user happens to have a weird path setting
one day, the installed C-Reduce doesn't break or change behavior. I think it
is good for installed things to be resilient in this way.
If there is some sort of envvar control, I would suggest that it be an override
of what gets burned in, not a replacement for burning things in. E.g., set
CREDUCE_<toolname>=<path> to override the burned-in setting.
Anyway, all the logic for this is wrapped up in a function,
`find_external_program' in "creduce_utils.pm". If we want to change the
strategy for finding stuff, it is easy to change it there.
Eric.