This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC V3 [1/2] test-in-container
- From: DJ Delorie <dj at redhat dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 25 Jun 2018 21:57:04 -0400
- Subject: Re: RFC V3 [1/2] test-in-container
Florian Weimer <fw@deneb.enyo.de> writes:
>> That would put the testroot itself under support/
>
> Are you sure? $(objdir) is used to define $(common-objpfx), after
> all.
The testroot is created by the toplevel Makefile, but test-container is
run from many different subdirectories. It needs to know what the
toplevel directory is. When building test-container in the support
subdir, $(objdir) points so the subdir:
gcc test-container.c ... -DOBJDIR_PATH=\"`cd /envy/dj/tools/upstream/glibc.testroot.build/support//..; pwd`\"
> You could bind mount in the container with the same path as outside
> the container.
I do.
Also, all the paths used inside the container need to work regardless of
what the current directory is.
> Useful for launching statically linked programs, for example.
> Currently, we need to pass in $(common-objpfx) from Makefile. See
> tst-getdate-ENV in time/Makefile for an example. Or the construct
> around tst-support_record_failure-2.out in support/Makefile.
Some of those cases could be candidates for conversion to
test-in-container, though, since the data files could be placed in their
"default" locations.
But sure, I could split those out. Or we could split them out later as
part of integrating them into whatever needs them. Personally, I'd
rather do it in conjunction with an actual use case, so it can be
tested.