[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 <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

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.