git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Phillip Wood <phillip.wood123@gmail.com>,
	Victoria Dye <vdye@github.com>,
	Eric Sunshine <ericsunshine@gmail.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v3 4/5] cmake: avoid editing t/test-lib.sh
Date: Tue, 18 Oct 2022 15:54:25 +0200	[thread overview]
Message-ID: <221018.86sfjlgr54.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <5b0c2a150e9fce1ca0284d65628b42ed5a7aad9a.1666090745.git.gitgitgadget@gmail.com>


On Tue, Oct 18 2022, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> In 7f5397a07c6c (cmake: support for testing git when building out of the
> source tree, 2020-06-26), we implemented support for running Git's test
> scripts even after building Git in a different directory than the source
> directory.
>
> The way we did this was to edit the file `t/test-lib.sh` to override
> `GIT_BUILD_DIR` to point somewhere else than the parent of the `t/`
> directory.
>
> This is unideal because it always leaves a tracked file marked as
> modified, and it is all too easy to commit that change by mistake.
>
> Let's change the strategy by teaching `t/test-lib.sh` to detect the
> presence of a file called `GIT-BUILD-DIR` in the source directory. If it
> exists, the contents are interpreted as the location to the _actual_
> build directory. We then write this file as part of the CTest
> definition.
>
> To support building Git via a regular `make` invocation after building
> it using CMake, we ensure that the `GIT-BUILD-DIR` file is deleted (for
> convenience, this is done as part of the Makefile rule that is already
> run with every `make` invocation to ensure that `GIT-BUILD-OPTIONS` is
> up to date).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Re my earlier feedback, I came up with this as an alternative, which
nicely allows us to have "cmake" and "make" play together, you can even
run them concurrently!:

	https://github.com/avar/git/commit/30f2265fd07aee97ea66f6e84a824d85d241e245

In case that OID changes it's on my
https://github.com/avar/git/commits/avar/cmake-test-path branch,
currently 30f2265fd07 (cmake & test-lib.sh: add a $GIT_SOURCE_DIR
variable, 2022-10-14).

And it...

> diff --git a/Makefile b/Makefile
> index 88178c5b466..886614340c7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3029,6 +3029,7 @@ else
>  	@echo RUNTIME_PREFIX=\'false\' >>$@+
>  endif
>  	@if cmp $@+ $@ >/dev/null 2>&1; then $(RM) $@+; else mv $@+ $@; fi
> +	@if test -f GIT-BUILD-DIR; then rm GIT-BUILD-DIR; fi

...allows us to get rid of this, which you understandably need with your
approach, but which I'd *really* prefer we not have. Let's not sneak
things into make's dependency DAG that it doesn't know about in FORCE'd
shell command (but more on that later).

>  ### Detect Python interpreter path changes
>  ifndef NO_PYTHON
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index 0c741e7d878..1d8cebb4cfe 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -1067,14 +1067,9 @@ endif()
>  #Make the tests work when building out of the source tree
>  get_filename_component(CACHE_PATH ${CMAKE_CURRENT_LIST_DIR}/../../CMakeCache.txt ABSOLUTE)
>  if(NOT ${CMAKE_BINARY_DIR}/CMakeCache.txt STREQUAL ${CACHE_PATH})
> -	file(RELATIVE_PATH BUILD_DIR_RELATIVE ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR}/CMakeCache.txt)
> -	string(REPLACE "/CMakeCache.txt" "" BUILD_DIR_RELATIVE ${BUILD_DIR_RELATIVE})
>  	#Setting the build directory in test-lib.sh before running tests
>  	file(WRITE ${CMAKE_BINARY_DIR}/CTestCustom.cmake
> -		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh GIT_BUILD_DIR_REPL REGEX \"GIT_BUILD_DIR=(.*)\")\n"
> -		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh content NEWLINE_CONSUME)\n"
> -		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY/../${BUILD_DIR_RELATIVE}\\\"\" content \"\${content}\")\n"
> -		"file(WRITE ${CMAKE_SOURCE_DIR}/t/test-lib.sh \${content})")
> +		"file(WRITE ${CMAKE_SOURCE_DIR}/GIT-BUILD-DIR \"${CMAKE_BINARY_DIR}\")")
>  	#misc copies
>  	file(COPY ${CMAKE_SOURCE_DIR}/t/chainlint.sed DESTINATION ${CMAKE_BINARY_DIR}/t/)
>  	file(COPY ${CMAKE_SOURCE_DIR}/po/is.po DESTINATION ${CMAKE_BINARY_DIR}/po/)

...and this whole section just goes away, we don't need any
cmake-specifi hacking here, and actually it's not cmake-specific at
all. It's just a "GIT_TEST_INSTALLED for things that are built, not
installed". E.g.:

            (cd g/git.scratch && make)
            (cd g/git && make clean && GIT_TEST_BUILD_DIR="$PWD/../git.scratch" make -C t)

Supporting cmake then just becomes a special-case of test-lib.sh knowing
"hey, my built stuff is at <dir> instead of "../".

> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 120f11812c3..dfc0144ed3b 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -47,6 +47,16 @@ then
>  	echo "PANIC: Running in a $TEST_DIRECTORY that doesn't end in '/t'?" >&2
>  	exit 1
>  fi
> +if test -f "$GIT_BUILD_DIR/GIT-BUILD-DIR"
> +then
> +	GIT_BUILD_DIR="$(cat "$GIT_BUILD_DIR/GIT-BUILD-DIR")" || exit 1
> +	# On Windows, we must convert Windows paths lest they contain a colon
> +	case "$(uname -s)" in
> +	*MINGW*)
> +		GIT_BUILD_DIR="$(cygpath -au "$GIT_BUILD_DIR")"
> +		;;
> +	esac
> +fi

...but one thing that I migh thave missed (and would really appreciate
your testing for) is that I didn't invoke cygpath in my version. CI
passes, but since Windows CI doesn't use "ctest" that doesn't tell us
much, and in any case that's Cygwin, no, which we don't run anyway
there?

Anyway, we could run that "cypath" easily in the cmake recipe itself, or
just pass a "hey, please make this canonical" flag to test-lib.sh.

But anyway, one thing that approach explicitly leaves out is that you
want to be able to:

 1. Build with cmake
 2. cd t
 3. Run a test

And have the test itself know to locate and use the cmake binaries
instead of the "main" binaries.

Now, I suspect that we don't actually have cases anyone cares about
where we have *both*, but that's how this code behaves. I.e. a
top-level:

	make test

Will wpe that GIT-BUILD-DIR and use the "make" built "git", but e.g.:

	make
	<build with cmake>
	cd t
	# At this point I forgot I used cmake earlier
	./t0001-init.sh # silently uses cmake...

I can see thy case for auto-discovery, per the IDE case you mentioned,
but isn't it much better to just make this part of the slightly later
part (but we need to set it up here now) part where we discover the
built "git" and:

 A. Do we not have it in ../git?
 B. Do we have it it contrib/buildsystems/out/git

Then (pseudocode):

	if (!A && B)
		use_cmake();
	else if (A && B)
		die("you have both, pick one!");

Or just say that "make" entry points always run with stuff it built, and
"ctest" runs with contrib/buildsystems/out/git, that's explicitly what
you don't want though...

Anyway, to wrap this up, I really wish the interaction between the two
wouldn't have these pitfalls. I get that you want to support it on the
specific Windows IDE case, but can't we more narrowlry do that without:

	(cd t && ./t0001-init.sh)

Having this new "pick either one" behavior? Cheers.
		



  reply	other threads:[~2022-10-18 14:09 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-10 15:02 [PATCH 0/5] Some fixes and an improvement for using CTest on Windows Johannes Schindelin via GitGitGadget
2022-08-10 15:02 ` [PATCH 1/5] cmake: align CTest definition with Git's CI runs Johannes Schindelin via GitGitGadget
2022-08-10 17:48   ` Junio C Hamano
2022-08-16 10:11     ` Johannes Schindelin
2022-08-16 15:15       ` Junio C Hamano
2022-08-19 13:57         ` Johannes Schindelin
2022-08-11 11:18   ` Ævar Arnfjörð Bjarmason
2022-08-10 15:02 ` [PATCH 2/5] cmake: copy the merge tools for testing Johannes Schindelin via GitGitGadget
2022-08-10 15:02 ` [PATCH 3/5] tests: explicitly skip `chmod` calls on Windows Johannes Schindelin via GitGitGadget
2022-08-11 11:22   ` Ævar Arnfjörð Bjarmason
2022-08-22 10:19     ` Johannes Schindelin
2022-08-23  7:34       ` Johannes Schindelin
2022-08-10 15:02 ` [PATCH 4/5] add -p: avoid ambiguous signed/unsigned comparison Johannes Schindelin via GitGitGadget
2022-08-10 17:54   ` Junio C Hamano
2022-08-16  9:56     ` Johannes Schindelin
2022-08-16 15:10       ` Junio C Hamano
2022-08-19 14:52         ` Johannes Schindelin
2022-08-11 12:49   ` Phillip Wood
2022-08-16 10:00     ` Johannes Schindelin
2022-08-16 14:23       ` Phillip Wood
2022-08-19 14:07         ` Johannes Schindelin
2022-08-10 15:02 ` [PATCH 5/5] cmake: avoid editing t/test-lib.sh Johannes Schindelin via GitGitGadget
2022-08-11 11:35   ` Ævar Arnfjörð Bjarmason
2022-10-18 14:02     ` Johannes Schindelin
2022-08-11 12:58   ` Phillip Wood
2022-08-16 10:09     ` Johannes Schindelin
2022-08-16 14:27       ` Phillip Wood
2022-08-23  8:30 ` [PATCH v2 0/5] Some fixes and an improvement for using CTest on Windows Johannes Schindelin via GitGitGadget
2022-08-23  8:30   ` [PATCH v2 1/5] cmake: make it easier to diagnose regressions in CTest runs Johannes Schindelin via GitGitGadget
2022-09-07 22:10     ` Victoria Dye
2022-10-18 14:02       ` Johannes Schindelin
2022-09-08  7:22     ` Ævar Arnfjörð Bjarmason
2022-09-28  6:55       ` Eric Sunshine
2022-08-23  8:31   ` [PATCH v2 2/5] cmake: copy the merge tools for testing Johannes Schindelin via GitGitGadget
2022-08-23  8:31   ` [PATCH v2 3/5] add -p: avoid ambiguous signed/unsigned comparison Johannes Schindelin via GitGitGadget
2022-08-23  8:31   ` [PATCH v2 4/5] cmake: avoid editing t/test-lib.sh Johannes Schindelin via GitGitGadget
2022-09-08  7:39     ` Ævar Arnfjörð Bjarmason
2022-10-18 14:03       ` Johannes Schindelin
2022-10-18 15:09         ` Ævar Arnfjörð Bjarmason
2022-09-08 23:37     ` Victoria Dye
2022-09-08 23:42       ` Victoria Dye
2022-09-08 23:58       ` Junio C Hamano
2022-10-18 14:03       ` Johannes Schindelin
2022-08-23  8:31   ` [PATCH v2 5/5] cmake: increase time-out for a long-running test Johannes Schindelin via GitGitGadget
2022-09-08  7:34     ` Ævar Arnfjörð Bjarmason
2022-09-08 17:29       ` Victoria Dye
2022-09-08  3:51   ` [PATCH v2 0/5] Some fixes and an improvement for using CTest on Windows Victoria Dye
2022-10-18 10:59   ` [PATCH v3 " Johannes Schindelin via GitGitGadget
2022-10-18 10:59     ` [PATCH v3 1/5] cmake: make it easier to diagnose regressions in CTest runs Johannes Schindelin via GitGitGadget
2022-10-18 13:41       ` Ævar Arnfjörð Bjarmason
2022-10-18 10:59     ` [PATCH v3 2/5] cmake: copy the merge tools for testing Johannes Schindelin via GitGitGadget
2022-10-18 13:49       ` Ævar Arnfjörð Bjarmason
2022-10-18 10:59     ` [PATCH v3 3/5] add -p: avoid ambiguous signed/unsigned comparison Johannes Schindelin via GitGitGadget
2022-10-18 13:53       ` Ævar Arnfjörð Bjarmason
2022-10-18 10:59     ` [PATCH v3 4/5] cmake: avoid editing t/test-lib.sh Johannes Schindelin via GitGitGadget
2022-10-18 13:54       ` Ævar Arnfjörð Bjarmason [this message]
2022-10-18 14:21         ` Johannes Schindelin
2022-10-18 10:59     ` [PATCH v3 5/5] cmake: increase time-out for a long-running test Johannes Schindelin via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=221018.86sfjlgr54.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=ericsunshine@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=phillip.wood123@gmail.com \
    --cc=vdye@github.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).