[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [creduce-dev] Finding `clang' at Run Time (Re: multifile creduce)
I also like the way we do things!
I was meaning that if we want to communicate a fixed piece of
information to clang_delta (the include path, as seen in one of Johan's
patches) I'd prefer to do that using the environment and not bother
C-Reduce with it.
If the information has to be changed by C-Reduce that's another story --
but that's not the case here.
On 10/21/15 12:06 AM, Eric Eide wrote:
John Regehr <email@example.com> 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
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.