Re: [creduce-dev] Finding `clang' at Run Time (Re: multifile creduce)

[Eric Eide <eeide@cs.utah.edu>]

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.

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .         University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX