On Dec 3, 2012, at 3:00 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> Mike, CCing you especially on the proposed lib/gcc-dg.exp dg-env-var
> changes and I have one question about cleanup of files (file delete
> vs. remote_file target (or is that host or build) delete).
> But of course if you could eyeball the rest and comment, I'd be even happier.
>> +file delete dlclose-test-1.exe-so.so
>> +file delete shared-lib-test-1.exe-so.so
>
> Ah, it is here, but wonder what it will do for cross testing.
> Shouldn't that be remove_file ? delete where ? is either target, or host, or
> build (not sure which one). Mike?
Sounds about right.
>> #
>> @@ -287,6 +327,10 @@ proc search_for { file pattern } {
>> # as c-torture does.
>> proc gcc-dg-runtest { testcases default-extra-flags } {
>> global runtests
>> + global set_env_var
>> +
>> + # Init set_env_var
>> + set set_env_var [list]
>>
>> # Some callers set torture options themselves; don't override those.
>> set existing_torture_options [torture-options-exist]
>
> For this, I'd appreciate Mike's input.
When documented, it will say if you want to change the environment variables on
the host, target or build machines. When it says which one, it will be
apparent when tested, if it does as documented. Since I don't know what you
guys want to do (better not to imagine one thinks they know)… I'd leave it to
you guys to figure it out and test. Also, if untested, I'd not see any reason
for it to work; but, maybe I'm just cautious that way. If you can only test
native, just bail out if not native, and try and recruit someone that can test
canadian or cross.
> If it is useful for all tests
> generally (I'd say it is, we could use it e.g. for testing some of the
> libgomp env vars), then it should stay here or so, otherwise it would need
> to be moved into asan-dg.exp and have asan in the name.
>
> More importantly, I'm wondering about dg-env-var vs. cross testing, I guess
> env var is set on host only, not remotely set on the target. So, either
> we should mark all tests that use dg-env-var with some special effective
> target that would be basically [is_native]
Ick, no.
> - or what is the way to limit tests to native testing only,
roughly:
if [is3way] || ! [isnative]
return
> or dg-evn-var itself should arrange to just
> make the whole test unsupported if not native (don't call ${tool}_load
> at all and return something else?).
If you want to expend the energy, it is easier to just fix the two lines that
are wrong and find some way to smuggle variables to the target. In the end, if
there is no existing way, you'd need to add a way and use it, and if that way
doesn't exist, either omit it, or unsupport it. Of course, that presupposes
you want environment variables on the target.
