This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Don't require test wrappers to preserve environment variables


I didn't closely vet the individual changes or that the log entries match.
I certainly support the thrust of the change.

I'd be a bit happier if the Makeconfig definitions used each other more and
duplicated each other less.  (If we can get to having fewer of them
altogether, that would be good too.)  For example, why is it not now:

test-wrapper = $(test-program-prefix-before-env) $(test-program-prefix-after-env)

?  Such simplifications could be done later, though.

> Where environment variable settings such as LC_ALL=C seemed plausibly
> relevant on both systems for cross testing, I left the existing
> settings in the scripts as well as having those variables passed
> explicitly to $(test-wrapper-env), so they remain set on both systems.

Any place where the environment variables on the build system matter, there
should be a comment explicitly saying that they do and why.  If there are
cases where you're just not sure that they don't matter, then add a generic
comment like "# ??? LC_ALL setting on build side might matter; figure out
whether and why." so that someone who wants to put the time into
understanding that particular test setup better can find the place easily
and then either remove the setting and comment or replace the comment with
one that gives specific rationale.

> One issue with this patch is that it's no longer so easy to pass
> TIMEOUTFACTOR through for cross testing.  Do people think
> cross-test-ssh.sh should special-case passing through that variable
> (but a whitelist of variables to pass in place of the previous
> blacklist of variables not to pass), or would it be better for it to
> have a --timeoutfactor command-line option that causes it to set
> TIMEOUTFACTOR on the remote system?

I think the command line option is better.  Having a simple rule that no
magic environment bits from the build host implicitly affect the test host
seems the least error-prone in the long run.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]