{"thread":{"id":"25442","subject":"[RFC PATCH] Makefile: new prove target for running the tests with TAP","startedAt":"2010-10-14T08:53:36Z","lastAt":"2010-10-29T13:19:20Z","messageCount":10,"participants":["Michael J Gruber","Ævar Arnfjörð Bjarmason","Jonathan Nieder","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"153495","messageId":"5c46df95f93b56aa2fce56c7efe7b2be80642c8b.1287045908.git.git@drmicha.warpmail.net","threadId":"25442","inReplyTo":null,"subject":"[RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-10-14T08:53:36Z","receivedAt":"2010-10-14T08:53:36Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Introduce a new make target \"prove\" which runs the tests via \"prove\" (or\n$(PROVE) if set) so that one does not have to cd around any more. One\ncan simply use \"make prove\" for \"make test\" or go wild as in:\n\nGIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' GIT_PROVE_OPTS=\"-j9 -v\" GIT_TEST_OPTS=\"--verbose --debug\" make prove\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\nRFC also because of lack of doc, and:\n\nCurrently, one can do\n\nmake -C t t6010-merge-base.sh\n\nor even\n\nmake -C t t601*\n\nwhich is cool but undocumented. If we want this with prove it requires more\neffort, or shoving prove into the $(T) target rule which is doable, of course.\nI'm just wondering whether it's accepted to introduce a specific rule for prove\nat all.\n\n Makefile   |    3 +++\n t/Makefile |    5 +++++\n 2 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 1f1ce04..3478515 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -2046,6 +2046,9 @@ export NO_SVN_TESTS\n test: all\n \t$(MAKE) -C t/ all\n \n+prove: all\n+\t$(MAKE) -C t/ prove\n+\n test-ctype$X: ctype.o\n \n test-date$X: date.o ctype.o\ndiff --git a/t/Makefile b/t/Makefile\nindex c7baefb..e4661c0 100644\n--- a/t/Makefile\n+++ b/t/Makefile\n@@ -11,6 +11,7 @@ SHELL_PATH ?= $(SHELL)\n PERL_PATH ?= /usr/bin/perl\n TAR ?= $(TAR)\n RM ?= rm -f\n+PROVE ?= prove\n \n # Shell quote;\n SHELL_PATH_SQ = $(subst ','\\'',$(SHELL_PATH))\n@@ -21,6 +22,10 @@ TSVN = $(wildcard t91[0-9][0-9]-*.sh)\n all: pre-clean\n \t$(MAKE) aggregate-results-and-cleanup\n \n+prove: pre-clean\n+\t@echo \"*** prove ***\"; GIT_CONFIG=.git/config $(PROVE) --exec '$(SHELL_PATH_SQ)' $(GIT_PROVE_OPTS) $(T) :: $(GIT_TEST_OPTS)\n+\t$(MAKE) clean\n+\n $(T):\n \t@echo \"*** $@ ***\"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)\n \n-- \n1.7.3.1.184.g5b1fd\n"},{"id":"153499","messageId":"AANLkTimuoanpbFbyv9C8qUbut22me1gMhH02eLqg0Nyd@mail.gmail.com","threadId":"25442","inReplyTo":"5c46df95f93b56aa2fce56c7efe7b2be80642c8b.1287045908.git.git@drmicha.warpmail.net","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-10-14T09:05:30Z","receivedAt":"2010-10-14T09:05:30Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Oct 14, 2010 at 08:53, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Introduce a new make target \"prove\" which runs the tests via \"prove\" (or\n> $(PROVE) if set) so that one does not have to cd around any more. One\n> can simply use \"make prove\" for \"make test\" or go wild as in:\n>\n> GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' GIT_PROVE_OPTS=\"-j9 -v\" GIT_TEST_OPTS=\"--verbose --debug\" make prove\n>\n> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n> ---\n> RFC also because of lack of doc, and:\n>\n> Currently, one can do\n>\n> make -C t t6010-merge-base.sh\n>\n> or even\n>\n> make -C t t601*\n>\n> which is cool but undocumented. If we want this with prove it requires more\n> effort, or shoving prove into the $(T) target rule which is doable, of course.\n> I'm just wondering whether it's accepted to introduce a specific rule for prove\n> at all.\n\nI like the rationale behind this, but fwiw. I already had a patch that\nwas ejected for this:\n\n    http://article.gmane.org/gmane.comp.version-control.git/146566\n\nQuoth Junio:\n\n    \"Besides, \"make -j15 test\" from the toplevel already runs the\n    tests in parallel.  I don't see much point in this change.\"\n\nBut I'd like to have it so that I could `make && make test_harness`\nand get readable test output.\n\nBut we should probably be using t/harness to run them, not\nprove(1). Then we would make the test_harness target respect the\nHARNESS_OPTIONS variable, which I e.g. have set to HARNESS_OPTIONS=j9\non my system.\n\n>\n>  Makefile   |    3 +++\n>  t/Makefile |    5 +++++\n>  2 files changed, 8 insertions(+), 0 deletions(-)\n>\n> diff --git a/Makefile b/Makefile\n> index 1f1ce04..3478515 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -2046,6 +2046,9 @@ export NO_SVN_TESTS\n>  test: all\n>        $(MAKE) -C t/ all\n>\n> +prove: all\n> +       $(MAKE) -C t/ prove\n> +\n>  test-ctype$X: ctype.o\n>\n>  test-date$X: date.o ctype.o\n> diff --git a/t/Makefile b/t/Makefile\n> index c7baefb..e4661c0 100644\n> --- a/t/Makefile\n> +++ b/t/Makefile\n> @@ -11,6 +11,7 @@ SHELL_PATH ?= $(SHELL)\n>  PERL_PATH ?= /usr/bin/perl\n>  TAR ?= $(TAR)\n>  RM ?= rm -f\n> +PROVE ?= prove\n>\n>  # Shell quote;\n>  SHELL_PATH_SQ = $(subst ','\\'',$(SHELL_PATH))\n> @@ -21,6 +22,10 @@ TSVN = $(wildcard t91[0-9][0-9]-*.sh)\n>  all: pre-clean\n>        $(MAKE) aggregate-results-and-cleanup\n>\n> +prove: pre-clean\n> +       @echo \"*** prove ***\"; GIT_CONFIG=.git/config $(PROVE) --exec '$(SHELL_PATH_SQ)' $(GIT_PROVE_OPTS) $(T) :: $(GIT_TEST_OPTS)\n> +       $(MAKE) clean\n> +\n>  $(T):\n>        @echo \"*** $@ ***\"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)\n>\n> --\n> 1.7.3.1.184.g5b1fd\n>\n>\n"},{"id":"153500","messageId":"4CB6CB97.7040009@drmicha.warpmail.net","threadId":"25442","inReplyTo":"AANLkTimuoanpbFbyv9C8qUbut22me1gMhH02eLqg0Nyd@mail.gmail.com","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-10-14T09:21:27Z","receivedAt":"2010-10-14T09:21:27Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Ævar Arnfjörð Bjarmason venit, vidit, dixit 14.10.2010 11:05:\n> On Thu, Oct 14, 2010 at 08:53, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Introduce a new make target \"prove\" which runs the tests via \"prove\" (or\n>> $(PROVE) if set) so that one does not have to cd around any more. One\n>> can simply use \"make prove\" for \"make test\" or go wild as in:\n>>\n>> GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' GIT_PROVE_OPTS=\"-j9 -v\" GIT_TEST_OPTS=\"--verbose --debug\" make prove\n>>\n>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n>> ---\n>> RFC also because of lack of doc, and:\n>>\n>> Currently, one can do\n>>\n>> make -C t t6010-merge-base.sh\n>>\n>> or even\n>>\n>> make -C t t601*\n>>\n>> which is cool but undocumented. If we want this with prove it requires more\n>> effort, or shoving prove into the $(T) target rule which is doable, of course.\n>> I'm just wondering whether it's accepted to introduce a specific rule for prove\n>> at all.\n> \n> I like the rationale behind this, but fwiw. I already had a patch that\n> was ejected for this:\n> \n>     http://article.gmane.org/gmane.comp.version-control.git/146566\n> \n> Quoth Junio:\n> \n>     \"Besides, \"make -j15 test\" from the toplevel already runs the\n>     tests in parallel.  I don't see much point in this change.\"\n> \n\nSorry for the kind of dupe then. Though I can understand that the fixed\noptions back then didn't find Junio's approval. Maybe it's different\nnow, when it's completely interchangeable with make test?\n\n> But I'd like to have it so that I could `make && make test_harness`\n> and get readable test output.\n> \n> But we should probably be using t/harness to run them, not\n> prove(1). Then we would make the test_harness target respect the\n> HARNESS_OPTIONS variable, which I e.g. have set to HARNESS_OPTIONS=j9\n> on my system.\n\nDidn't know about that one either. What does t/harness\ndifferently/better from/than prove? Does it take the same options? Is\nt/harness respecting the SHELL_PATH for the tests? Running a test under\nmake test and make prove/harness needs to be completely equivalent.\n\nMichael\n"},{"id":"153502","messageId":"AANLkTinDq4FOZd7v5C8HZ7S81xoO6nJZTEe4+-9AO8HQ@mail.gmail.com","threadId":"25442","inReplyTo":"4CB6CB97.7040009@drmicha.warpmail.net","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-10-14T09:33:11Z","receivedAt":"2010-10-14T09:33:11Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Oct 14, 2010 at 09:21, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Ævar Arnfjörð Bjarmason venit, vidit, dixit 14.10.2010 11:05:\n>> On Thu, Oct 14, 2010 at 08:53, Michael J Gruber\n>> <git@drmicha.warpmail.net> wrote:\n>>> Introduce a new make target \"prove\" which runs the tests via \"prove\" (or\n>>> $(PROVE) if set) so that one does not have to cd around any more. One\n>>> can simply use \"make prove\" for \"make test\" or go wild as in:\n>>>\n>>> GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' GIT_PROVE_OPTS=\"-j9 -v\" GIT_TEST_OPTS=\"--verbose --debug\" make prove\n>>>\n>>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n>>> ---\n>>> RFC also because of lack of doc, and:\n>>>\n>>> Currently, one can do\n>>>\n>>> make -C t t6010-merge-base.sh\n>>>\n>>> or even\n>>>\n>>> make -C t t601*\n>>>\n>>> which is cool but undocumented. If we want this with prove it requires more\n>>> effort, or shoving prove into the $(T) target rule which is doable, of course.\n>>> I'm just wondering whether it's accepted to introduce a specific rule for prove\n>>> at all.\n>>\n>> I like the rationale behind this, but fwiw. I already had a patch that\n>> was ejected for this:\n>>\n>>     http://article.gmane.org/gmane.comp.version-control.git/146566\n>>\n>> Quoth Junio:\n>>\n>>     \"Besides, \"make -j15 test\" from the toplevel already runs the\n>>     tests in parallel.  I don't see much point in this change.\"\n>>\n>\n> Sorry for the kind of dupe then. Though I can understand that the fixed\n> options back then didn't find Junio's approval. Maybe it's different\n> now, when it's completely interchangeable with make test?\n\nMaybe. I try not to decipher him too much :)\n\nBut a patch for this that'd be acceptable would be great. Good that\nyou're working on it.\n\n>> But I'd like to have it so that I could `make && make test_harness`\n>> and get readable test output.\n>>\n>> But we should probably be using t/harness to run them, not\n>> prove(1). Then we would make the test_harness target respect the\n>> HARNESS_OPTIONS variable, which I e.g. have set to HARNESS_OPTIONS=j9\n>> on my system.\n>\n> Didn't know about that one either. What does t/harness\n> differently/better from/than prove? Does it take the same options? Is\n> t/harness respecting the SHELL_PATH for the tests? Running a test under\n> make test and make prove/harness needs to be completely equivalent.\n\nt/harness is just using the library that prove(1) uses directly. We\nalready use it for \"make smoke\". The advantage is that you can run\ncustom setup code there, e.g. this is from perl.git's own t/harness:\n\n    my $jobs = $ENV{TEST_JOBS};\n    my ($rules, $state, $color);\n    if ($ENV{HARNESS_OPTIONS}) {\n        for my $opt ( split /:/, $ENV{HARNESS_OPTIONS} ) {\n            if ( $opt =~ /^j(\\d*)$/ ) {\n                $jobs ||= $1 || 9;\n            }\n            elsif ( $opt eq 'c' ) {\n                $color = 1;\n            }\n            else {\n                die \"Unknown HARNESS_OPTIONS item: $opt\\n\";\n            }\n        }\n    }\n\nSo if we expanded t/harness to use that and added a \"test_harness\"\ntarget we could make it grok the TEST_JOBS and HARNESS_OPTIONS\nenvironment variables.\n\nThe output would be the same (see \"make smoke\"), and we can make it\nrespect SHELL_PATH.\n"},{"id":"153520","messageId":"20101014162757.GC16500@burratino","threadId":"25442","inReplyTo":"5c46df95f93b56aa2fce56c7efe7b2be80642c8b.1287045908.git.git@drmicha.warpmail.net","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-14T16:27:57Z","receivedAt":"2010-10-14T16:27:57Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael J Gruber wrote:\n\n> Introduce a new make target \"prove\" which runs the tests via \"prove\"\n\nI like it. :)\n\nI've been using\n\n\tprove -j2 --shuffle t[0-9]*.sh\n\nand would be happier to be able to dump GIT_PROVE_OPTS=\"-j2 --shuffle\"\nin my config.mak and just run \"make prove\" instead of that unwieldly\nglob.\n\n> RFC also because of lack of doc, and:\n> \n> Currently, one can do\n> \n> make -C t t6010-merge-base.sh\n> \n> or even\n> \n> make -C t t601*\n> \n> which is cool but undocumented. If we want this with prove it requires more\n> effort\n\nDoesn't \"prove t601*\" work well for that use case already?\n\n> --- a/t/Makefile\n> +++ b/t/Makefile\n[...]\n> +prove: pre-clean\n> +\t@echo \"*** prove ***\"; GIT_CONFIG=.git/config $(PROVE) --exec '$(SHELL_PATH_SQ)' $(GIT_PROVE_OPTS) $(T) :: $(GIT_TEST_OPTS)\n> +\t$(MAKE) clean\n> +\n>  $(T):\n>  \t@echo \"*** $@ ***\"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)\n\nNot about this patch, but is that GIT_CONFIG setting needed?  I would have\nguessed rather that test-lib.sh would unset GIT_CONFIG as soon as possible.\n"},{"id":"153525","messageId":"20101014172301.GA2770@sigill.intra.peff.net","threadId":"25442","inReplyTo":"5c46df95f93b56aa2fce56c7efe7b2be80642c8b.1287045908.git.git@drmicha.warpmail.net","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-14T17:23:02Z","receivedAt":"2010-10-14T17:23:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 14, 2010 at 10:53:36AM +0200, Michael J Gruber wrote:\n\n> +prove: pre-clean\n> +\t@echo \"*** prove ***\"; GIT_CONFIG=.git/config $(PROVE) --exec '$(SHELL_PATH_SQ)' $(GIT_PROVE_OPTS) $(T) :: $(GIT_TEST_OPTS)\n> +\t$(MAKE) clean\n> +\n\nI like the idea. I think the prove output is a little nicer for things\nlike -j16, but it's a pain to construct the command line (especially as\nI use --root in GIT_TEST_OPTS to get a significant speedup).\n\nI wonder if anybody is really interested in switching between the\n\"prove\" and regular test targets, though. I would think you either like\nto use prove or not. So perhaps it makes more sense to put a\nconfigurable switch for the default target, like the patch below. Then\nyou can just \"make test\" (or \"make\" in the test directory) as usual.\n\ndiff --git a/t/Makefile b/t/Makefile\nindex c7baefb..2b4d4ac 100644\n--- a/t/Makefile\n+++ b/t/Makefile\n@@ -11,6 +11,8 @@ SHELL_PATH ?= $(SHELL)\n PERL_PATH ?= /usr/bin/perl\n TAR ?= $(TAR)\n RM ?= rm -f\n+PROVE ?= prove\n+DEFAULT_TEST_TARGET ?= test\n \n # Shell quote;\n SHELL_PATH_SQ = $(subst ','\\'',$(SHELL_PATH))\n@@ -18,9 +20,15 @@ SHELL_PATH_SQ = $(subst ','\\'',$(SHELL_PATH))\n T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)\n TSVN = $(wildcard t91[0-9][0-9]-*.sh)\n \n-all: pre-clean\n+all: $(DEFAULT_TEST_TARGET)\n+\n+test: pre-clean\n \t$(MAKE) aggregate-results-and-cleanup\n \n+prove: pre-clean\n+\t@echo \"*** prove ***\"; GIT_CONFIG=.git/config $(PROVE) --exec '$(SHELL_PATH_SQ)' $(GIT_PROVE_OPTS) $(T) :: $(GIT_TEST_OPTS)\n+\t$(MAKE) clean\n+\n $(T):\n \t@echo \"*** $@ ***\"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)\n \n"},{"id":"154468","messageId":"7vmxq0ebe9.fsf@alter.siamese.dyndns.org","threadId":"25442","inReplyTo":"20101014172301.GA2770@sigill.intra.peff.net","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-27T00:18:22Z","receivedAt":"2010-10-27T00:18:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Thu, Oct 14, 2010 at 10:53:36AM +0200, Michael J Gruber wrote:\n>\n>> +prove: pre-clean\n>> +\t@echo \"*** prove ***\"; GIT_CONFIG=.git/config $(PROVE) --exec '$(SHELL_PATH_SQ)' $(GIT_PROVE_OPTS) $(T) :: $(GIT_TEST_OPTS)\n>> +\t$(MAKE) clean\n>> +\n>\n> I like the idea. I think the prove output is a little nicer for things\n> like -j16, but it's a pain to construct the command line (especially as\n> I use --root in GIT_TEST_OPTS to get a significant speedup).\n>\n> I wonder if anybody is really interested in switching between the\n> \"prove\" and regular test targets, though. I would think you either like\n> to use prove or not. So perhaps it makes more sense to put a\n> configurable switch for the default target, like the patch below. Then\n> you can just \"make test\" (or \"make\" in the test directory) as usual.\n\nI kind of like this.  Perhaps with something like this squashed in?\n\n-- >8 --\ntest: allow \"prove\" to be used as the main test harness\n\nThe prove output is a little easier to read for things like -j16.\n\n---\n t/README |    6 ++++++\n 1 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/t/README b/t/README\nindex a1eb7c8..c548bf1 100644\n--- a/t/README\n+++ b/t/README\n@@ -50,6 +50,12 @@ prove and other harnesses come with a lot of useful options. The\n     # Repeat until no more failures\n     $ prove -j 15 --state=failed,save ./t[0-9]*.sh\n \n+You can give DEFAULT_TEST_TARGET=prove on the make command (or define it\n+in config.mak) to cause \"make test\" to run tests under prove.\n+GIT_PROVE_OPTS can be used to pass additional options, e.g.\n+\n+    $ make DEFAULT_TEST_TARGET=prove GIT_PROVE_OPTS='--timer --jobs 16' test\n+\n You can also run each test individually from command line, like this:\n \n     $ sh ./t3010-ls-files-killed-modified.sh\n"},{"id":"154474","messageId":"20101027045709.GA11250@idm.gtisc.gatech.edu","threadId":"25442","inReplyTo":"7vmxq0ebe9.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-27T04:57:09Z","receivedAt":"2010-10-27T04:57:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 26, 2010 at 05:18:22PM -0700, Junio C Hamano wrote:\n\n> > like -j16, but it's a pain to construct the command line (especially as\n> > I use --root in GIT_TEST_OPTS to get a significant speedup).\n> [..]\n> I kind of like this.  Perhaps with something like this squashed in?\n\nYeah, looks good to me. I guess you can steal the commit message and\nauthorship from Michael's original.\n\nÆvar mentioned something about t/harness, which I honestly have no idea\nabout (I don't have the right perl modules installed to run it). But\nmaybe that could be an alternate DEFAULT_TEST_TARGET. I dunno.\n\n-Peff\n"},{"id":"154488","messageId":"AANLkTimH=fbRAdz-F-V-9WTKzAyVvpzRHC06e+94a2wJ@mail.gmail.com","threadId":"25442","inReplyTo":"20101027045709.GA11250@idm.gtisc.gatech.edu","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-10-27T11:00:15Z","receivedAt":"2010-10-27T11:00:15Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Oct 27, 2010 at 06:57, Jeff King <peff@peff.net> wrote:\n> On Tue, Oct 26, 2010 at 05:18:22PM -0700, Junio C Hamano wrote:\n>\n>> > like -j16, but it's a pain to construct the command line (especially as\n>> > I use --root in GIT_TEST_OPTS to get a significant speedup).\n>> [..]\n>> I kind of like this.  Perhaps with something like this squashed in?\n>\n> Yeah, looks good to me. I guess you can steal the commit message and\n> authorship from Michael's original.\n>\n> Ævar mentioned something about t/harness, which I honestly have no idea\n> about (I don't have the right perl modules installed to run it). But\n> maybe that could be an alternate DEFAULT_TEST_TARGET. I dunno.\n\nThe non-standard module there is only needed for the smoke testing.\n\nIf we used t/harness for running \"make test\" that code could be\nmodified to run anywhere prove itself does.\n\nAnyway, if there's a patch now to invoke prove(1) let's use that. We\ncan change it to t/harness later if that makes sense.\n"},{"id":"154782","messageId":"4CCAC9D8.20501@drmicha.warpmail.net","threadId":"25442","inReplyTo":"AANLkTimH=fbRAdz-F-V-9WTKzAyVvpzRHC06e+94a2wJ@mail.gmail.com","subject":"Re: [RFC PATCH] Makefile: new prove target for running the tests with TAP","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-10-29T13:19:20Z","receivedAt":"2010-10-29T13:19:20Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Ævar Arnfjörð Bjarmason venit, vidit, dixit 27.10.2010 13:00:\n> On Wed, Oct 27, 2010 at 06:57, Jeff King <peff@peff.net> wrote:\n>> On Tue, Oct 26, 2010 at 05:18:22PM -0700, Junio C Hamano wrote:\n>>\n>>>> like -j16, but it's a pain to construct the command line (especially as\n>>>> I use --root in GIT_TEST_OPTS to get a significant speedup).\n>>> [..]\n>>> I kind of like this.  Perhaps with something like this squashed in?\n>>\n>> Yeah, looks good to me. I guess you can steal the commit message and\n>> authorship from Michael's original.\n>>\n>> Ævar mentioned something about t/harness, which I honestly have no idea\n>> about (I don't have the right perl modules installed to run it). But\n>> maybe that could be an alternate DEFAULT_TEST_TARGET. I dunno.\n> \n> The non-standard module there is only needed for the smoke testing.\n> \n> If we used t/harness for running \"make test\" that code could be\n> modified to run anywhere prove itself does.\n> \n> Anyway, if there's a patch now to invoke prove(1) let's use that. We\n> can change it to t/harness later if that makes sense.\n\nThanks, Junio, for taking this up (and others for discussing it), I've\nbeen out of the loop a bit. I'll try and keep up with my other\nhalf-baked patches ;)\n\nMichael\n"}]}