{"thread":{"id":"61191","subject":"[PATCH] t/README: mention test files are make targets","startedAt":"2024-03-24T15:14:09Z","lastAt":"2024-03-25T19:01:57Z","messageCount":6,"participants":["Philippe Blain via GitGitGadget","Junio C Hamano","Philippe Blain","Chris Torek"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"491353","messageId":"pull.1701.git.1711293246094.gitgitgadget@gmail.com","threadId":"61191","inReplyTo":null,"subject":"[PATCH] t/README: mention test files are make targets","fromName":"Philippe Blain via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2024-03-24T15:14:05Z","receivedAt":"2024-03-24T15:14:09Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"From: Philippe Blain \n\nSince 23fc63bf8f (make tests ignorable with \"make -i\", 2005-11-08), each\ntest file defines a target in the test Makefile, such that one can\ninvoke:\n\n\tmake *checkout*\n\nto run all tests with 'checkout' in their filename. This is useful to\nrun a subset of tests when you have a good idea of what part of the code\nis touched by the changes your are testing.\n\nDocument that in t/README to help new (or more seasoned) contributors\nthat might not be aware.\n\nSigned-off-by: Philippe Blain \n---\n t/README: mention test files are make targets\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1701%2Fphil-blain%2Ftests-makefile-targets-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1701/phil-blain/tests-makefile-targets-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1701\n\n t/README | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/t/README b/t/README\nindex 621d3b8c095..71211109338 100644\n--- a/t/README\n+++ b/t/README\n@@ -32,6 +32,13 @@ the tests.\n ok 2 - plain with GIT_WORK_TREE\n ok 3 - plain bare\n \n+t/Makefile defines a target for each test file, such that you can also use\n+shell pattern matching to run a subset of the tests:\n+\n+ make *checkout*\n+\n+will run all tests with 'checkout' in their filename.\n+\n Since the tests all output TAP (see https://testanything.org) they can\n be run with any TAP harness. Here's an example of parallel testing\n powered by a recent version of prove(1):\n\nbase-commit: 3e0d3cd5c7def4808247caf168e17f2bbf47892b\n-- \ngitgitgadget\n"},{"id":"491359","messageId":"xmqq4jcvtxtz.fsf@gitster.g","threadId":"61191","inReplyTo":"pull.1701.git.1711293246094.gitgitgadget@gmail.com","subject":"Re: [PATCH] t/README: mention test files are make targets","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-24T16:10:32Z","receivedAt":"2024-03-24T16:10:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philippe Blain via GitGitGadget\" writes:\n\n> From: Philippe Blain \n>\n> Since 23fc63bf8f (make tests ignorable with \"make -i\", 2005-11-08), each\n> test file defines a target in the test Makefile, such that one can\n> invoke:\n>\n> \tmake *checkout*\n>\n> to run all tests with 'checkout' in their filename. This is useful to\n> run a subset of tests when you have a good idea of what part of the code\n> is touched by the changes your are testing.\n\nWhile I agree with the patch that this is a useful \"feature\" of\nt/Makefile, I've always felt it was ugly to use a file itself that\nwe do not consider a build product, rather a source, as the target\nto trigger some action. Are we comfortable casting this behaviour\nin stone by documenting it here? Just checking by asking others, as\nyou are obviously comfortable enough to write this patch ;-)\n\nThanks.\n\n> Document that in t/README to help new (or more seasoned) contributors\n> that might not be aware.\n>\n> Signed-off-by: Philippe Blain \n> ---\n> t/README: mention test files are make targets\n>\n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1701%2Fphil-blain%2Ftests-makefile-targets-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1701/phil-blain/tests-makefile-targets-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/1701\n>\n> t/README | 7 +++++++\n> 1 file changed, 7 insertions(+)\n>\n> diff --git a/t/README b/t/README\n> index 621d3b8c095..71211109338 100644\n> --- a/t/README\n> +++ b/t/README\n> @@ -32,6 +32,13 @@ the tests.\n> ok 2 - plain with GIT_WORK_TREE\n> ok 3 - plain bare\n> \n> +t/Makefile defines a target for each test file, such that you can also use\n> +shell pattern matching to run a subset of the tests:\n> +\n> + make *checkout*\n> +\n> +will run all tests with 'checkout' in their filename.\n> +\n> Since the tests all output TAP (see https://testanything.org) they can\n> be run with any TAP harness. Here's an example of parallel testing\n> powered by a recent version of prove(1):\n>\n> base-commit: 3e0d3cd5c7def4808247caf168e17f2bbf47892b\n"},{"id":"491365","messageId":"97212b72-70d6-e55f-8b2a-04ede4321288@gmail.com","threadId":"61191","inReplyTo":"xmqq4jcvtxtz.fsf@gitster.g","subject":"Re: [PATCH] t/README: mention test files are make targets","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2024-03-24T17:04:34Z","receivedAt":"2024-03-24T17:04:36Z","isPatch":true,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Junio,\n\nLe 2024-03-24 à 12:10, Junio C Hamano a écrit :\n> \"Philippe Blain via GitGitGadget\" writes:\n> \n>> From: Philippe Blain \n>>\n>> Since 23fc63bf8f (make tests ignorable with \"make -i\", 2005-11-08), each\n>> test file defines a target in the test Makefile, such that one can\n>> invoke:\n>>\n>> \tmake *checkout*\n>>\n>> to run all tests with 'checkout' in their filename. This is useful to\n>> run a subset of tests when you have a good idea of what part of the code\n>> is touched by the changes your are testing.\n> \n> While I agree with the patch that this is a useful \"feature\" of\n> t/Makefile, I've always felt it was ugly to use a file itself that\n> we do not consider a build product, rather a source, as the target\n> to trigger some action. Are we comfortable casting this behaviour\n> in stone by documenting it here?\n\nSince '$(T)' is listed at the bottom of the Makefile as .PHONY,\nI think it is OK and not that ugly since this uses a documented feature\nof make.\n\nCheers,\nPhilippe.\n"},{"id":"491388","messageId":"xmqqfrwfp0hh.fsf@gitster.g","threadId":"61191","inReplyTo":"97212b72-70d6-e55f-8b2a-04ede4321288@gmail.com","subject":"Re: [PATCH] t/README: mention test files are make targets","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-25T01:24:26Z","receivedAt":"2024-03-25T01:24:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philippe Blain writes:\n\n> Since '$(T)' is listed at the bottom of the Makefile as .PHONY,\n> I think it is OK and not that ugly since this uses a documented feature\n> of make.\n\nYou're prehaps right.\n\nI've always felt that the documented .PHONY feature was to mark\ntargets that do not correspond to any filename on the filesystem,\ne.g., \"all\", \"clean\", \"install\". Of course these can exist as\nfilenames as well, and .PHONY works as an instruction that says \"the\nexistence or freshness of these targets do not matter at all\". For\nour use, it is OK.\n\nI however wonder if marking $(T) as .PHONY is the right thing to\nbegin with. Declaring that the existence or freshness of\nt0000-basic.sh does not matter means we will not be able to later\nwrite rules other than \"just run it!\" that does depend on the\nfreshness of t0000-basic.sh file, no? IOW, if we wanted to add a\ntarget like this at the end of the t/Makefile:\n\n t-combined.sh: t0000-basic.sh t0001-init.sh\n cat t0000-basic.sh t0001-init.sh >\"$@\"\n\nthen \"make -C t t-combined.sh\" would end up running these two test\nscripts (because they are .PHONY) and then leave the concatenation\nin t-combined.sh file. Without changing anything, doing the same\n\"make -C t t-combined.sh\" again will again run these two tests and\nrecreate the same t-combined.sh file, even though there is no need\nto.\n\nSo I think that is what I felt ugly.\n\nAs long as we do not use these $(T) files as an input to some other\nthing and list them as the dependencies, we are OK, though.\n\n"},{"id":"491413","messageId":"CAPx1GvcPEeC3HTdb4bUYASz-t=a7Z2MEUamB4QyO44y4MRy6Pw@mail.gmail.com","threadId":"61191","inReplyTo":"xmqqfrwfp0hh.fsf@gitster.g","subject":"Re: [PATCH] t/README: mention test files are make targets","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2024-03-25T09:59:15Z","receivedAt":"2024-03-25T09:59:28Z","isPatch":true,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Mar 25, 2024 at 2:49 AM Junio C Hamano wrote:\n> As long as we do not use these $(T) files as an input to some other\n> thing and list them as the dependencies, we are OK, though.\n\nYou could (maybe later / at need) stop listing them as `.PHONY` and\ninstead use:\n\n $(T)::\n sh -c ./$@\n\nor similar, so that some $(T) *can* be an input. Note that this requires\nusing double-colon rules earlier to build the test.\n\nI wouldn't do this without a pretty strong reason though.\n\nChris\n"},{"id":"491491","messageId":"xmqqsf0ejftz.fsf@gitster.g","threadId":"61191","inReplyTo":"CAPx1GvcPEeC3HTdb4bUYASz-t=a7Z2MEUamB4QyO44y4MRy6Pw@mail.gmail.com","subject":"Re: [PATCH] t/README: mention test files are make targets","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-25T19:01:44Z","receivedAt":"2024-03-25T19:01:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Torek writes:\n\n> On Mon, Mar 25, 2024 at 2:49 AM Junio C Hamano wrote:\n>> As long as we do not use these $(T) files as an input to some other\n>> thing and list them as the dependencies, we are OK, though.\n>\n> You could (maybe later / at need) stop listing them as `.PHONY` and\n> instead use:\n>\n> $(T)::\n> sh -c ./$@\n>\n> or similar, so that some $(T) *can* be an input. Note that this requires\n> using double-colon rules earlier to build the test.\n>\n> I wouldn't do this without a pretty strong reason though.\n\nMe neither.\n\nI personally think a target that is marked as .PHONY and does not\nuse double-colon rule is a bug by itself but that is a separate\nstory.\n\nIn any case, just to avoid leaving the thread hanging, I'll take the\npatch as is, as it documents a useful trick in the status quo.\n\nThanks, all.\n"}]}