This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Don't require test wrappers to preserve environment variables
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 23 May 2014 15:27:12 -0700 (PDT)
- Subject: Re: Don't require test wrappers to preserve environment variables
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1405211643220 dot 13941 at digraph dot polyomino dot org dot uk>
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