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: 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.


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