On 12/13, Lars Schneider wrote: > > > On 13 Dec 2017, at 18:38, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Lars Schneider <larsxschneider@xxxxxxxxx> writes: > > > >> I think your solution points into the right direction. > >> Right now we have the following test matrix: > >> > >> 1. Linux - clang > >> 2. Linux - gcc > >> 3. Mac - clang > >> 4. Mac - gcc > >> 5. Linux - gcc - GET_TEXT_POISION > >> 6. Linux - gcc - 32bit > >> 7. Windows > >> > >> AFAIK your solution would run the split index test for > >> 1, 2, 3, and 4. I think that is too much. > > > > Not that it matters too much, but I meant to add it to 1. and > > 6. when I said "only one of 64-bit build plus 32-bit one". > > Ah. Sorry, I didn't get that. > > > >> 1 runs the fastest and I would like to keep it that way > >> to get a quick "general" result. I think only 2 should be > >> extended in the way you are suggesting. We could run > >> the tests with different env variables there. What else > >> do we have besides GIT_TEST_SPLIT_INDEX? > >> > >> Would that work for everyone? > > > > I am OK to make 2. use split-index (which unfortunately would mean > > we lose tests without split-index under gcc), or add 2.5 that is a > > copy of 2. plus split-index. > > > I think I experessed myself poorly. As far as I understand it, > GIT_TEST_SPLIT_INDEX is an environment variable that only needs > to be set at test time and not at compile time. Is this right? Yes, that's correct. > If yes, my idea for 2. is as follows: > - build Git with gcc > - run tests with "make --quiet test" > - run tests with "GIT_TEST_SPLIT_INDEX=YesPlease make --quiet test" > > This should be quicker than a new 2.5 target because we don't need to > spin up the machine and build Git. Plus, we could run the tests > a few more times with other test flags. I'd be happy with that. Thanks for the discussion on this, will change this in my re-roll. > - Lars
