Patrick Steinhardt wrote: > On Mon, Jul 19, 2021 at 05:42:59AM -0500, Felipe Contreras wrote: > > Jeff King wrote: > > > On Mon, Jul 19, 2021 at 02:53:30AM -0500, Felipe Contreras wrote: > > > > > > > Patrick Steinhardt wrote: > > > > > On Tue, Jul 13, 2021 at 06:07:12PM -0700, Junio C Hamano wrote: > > > > > [snip] > > > > > > * ps/perf-with-separate-output-directory (2021-07-02) 1 commit > > > > > > - perf: fix when running with TEST_OUTPUT_DIRECTORY > > > > > > > > > > > > Test update. > > > > > > > > > > > > What's the status of this one? > > > > > > > > > > From my point of view this is ready, but it's still missing reviews so > > > > > far. The lack of interest seems to indicate that nobody has hit the > > > > > issue so far, and I wonder why that is. Am I the only one who sets > > > > > TEST_OUTPUT_DIRECTORY to a tmpfs directory in his config.mak to speed up > > > > > tests? > > > > > > > > No, I do the same, and this other fix for TEST_OUTPUT_DIRECTORY is being > > > > ignored even harder: > > > > > > > > https://lore.kernel.org/git/20210707030709.3134859-1-felipe.contreras@xxxxxxxxx/ > > > > > > Note that the linked patch will break Patrick's, because we would no > > > longer set TEST_OUTPUT_DIRECTORY in GIT-BUILD-OPTIONS. > > > > Is Patrick's patch specific to GIT-BUILD-OPTIONS? Or can > > TEST_OUTPUT_DIRECTORY be taken from the environment? > > > > Either way I think the priority should be to make the standard tests > > work with TEST_OUTPUT_DIRECTORY. > > Right now, TEST_OUTPUT_DIRECTORY as defined in config.mak will be > written into GIT-BUILD-OPTIONS, which then gets sourced by test-lib.sh > automatically. So even if you execute tests directly and not via the > Makefile, it'll still pick up the correct output directory you've > specified in your config.mak. Yeah, I know, but right now if you do that t0000-basic.sh fails because _run_sub_test_lib_test_common sets TEST_OUTPUT_DIRECTORY on the environment, and that gets overriden when GIT-BUILD-OPTIONS is sourced. > It would likely be possible to take it from the environment, but that > makes the calling interface much more fragile given that you'll have > to remember to always set the envvar. Indeed, unless you set that in your ~/.profile, as I did. -- Felipe Contreras