Windows: force-recompile git.res for differing architectures
cover Windows: force-recompile git.res for differing architectures
This is a patch designed to help maintaining Git for Windows better: when the same source code is "cross-compiled" for i686 as well as x86_64, we want to rebuild the whole thing, including the resource file git.res.
Note: regular C files are re-compiled appropriately, as the default prefix in Git for Windows is /mingw32 or /mingw64 depending on the architecture, and this difference is manifested in the CFLAGS (which, upon change, trigger a complete rebuild).
As non-Windows platforms do not even compile these .res files, this patch should have exactly no effect on non-Windows builds.
Johannes Schindelin (1):
Windows: force-recompile git.res for differing architectures
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: cd69ec8cde54af1817630331fc441f493866f0d4
Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-67%2Fdscho%2Fmingw-git.res-bitness-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-67/dscho/mingw-git.res-bitness-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/67
Signature · 1 line
gitgitgadget
PATCH 1/1 Windows: force-recompile git.res for differing architectures
From: Johannes Schindelin <[email protected]>
When git.rc is compiled into git.res, the result is actually dependent on the architecture. That is, you cannot simply link a 32-bit git.res into a 64-bit git.exe.
Therefore, to allow 32-bit and 64-bit builds in the same directory, we let git.res depend on GIT-PREFIX so that it gets recompiled when compiling for a different architecture (this works because the exec path changes based on the architecture: /mingw32/libexec/git-core for 32-bit and /mingw64/libexec/git-core for 64-bit).
--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Makefile +1 -1
@@ -2110,7 +2110,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES $(QUIET_GEN)$(cmd_munge_script) && \ mv $@+ $@ -git.res: git.rc GIT-VERSION-FILE +git.res: git.rc GIT-VERSION-FILE GIT-PREFIX $(QUIET_RC)$(RC) \ $(join -DMAJOR= -DMINOR= -DMICRO= -DPATCHLEVEL=, $(wordlist 1, 4, \ $(shell echo $(GIT_VERSION) 0 0 0 0 | tr '.a-zA-Z-' ' '))) \
Signature · 1 line
gitgitgadget
Am 06.11.18 um 15:55 schrieb Johannes Schindelin via GitGitGadget:
Quoted 11 lines
From: Johannes Schindelin <[email protected]>
When git.rc is compiled into git.res, the result is actually dependent on the architecture. That is, you cannot simply link a 32-bit git.res into a 64-bit git.exe.
Therefore, to allow 32-bit and 64-bit builds in the same directory, we let git.res depend on GIT-PREFIX so that it gets recompiled when compiling for a different architecture (this works because the exec path changes based on the architecture: /mingw32/libexec/git-core for 32-bit and /mingw64/libexec/git-core for 64-bit).
On Linux, when I recompile for a different architecture, CFLAGS would change, so I would have thought that GIT-CFLAGS were the natural choice for a dependency. Don't they change in this case on Windows, too?
Quoted 20 lines
Signed-off-by Johannes Schindelin <[email protected]>--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Makefile +1
-1@@ -2110,7 +2110,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES $(QUIET_GEN)$(cmd_munge_script) && \ mv $@+ $@ -git.res: git.rc GIT-VERSION-FILE +git.res: git.rc GIT-VERSION-FILE GIT-PREFIX $(QUIET_RC)$(RC) \ $(join -DMAJOR= -DMINOR= -DMICRO= -DPATCHLEVEL=, $(wordlist 1, 4, \ $(shell echo $(GIT_VERSION) 0 0 0 0 | tr '.a-zA-Z-' ' '))) \
Quoted 13 lines · Johannes Sixt
Am 06.11.18 um 15:55 schrieb Johannes Schindelin via GitGitGadget:
Quoted 11 lines
From: Johannes Schindelin <[email protected]>
When git.rc is compiled into git.res, the result is actually dependent on the architecture. That is, you cannot simply link a 32-bit git.res into a 64-bit git.exe.
Therefore, to allow 32-bit and 64-bit builds in the same directory, we let git.res depend on GIT-PREFIX so that it gets recompiled when compiling for a different architecture (this works because the exec path changes based on the architecture: /mingw32/libexec/git-core for 32-bit and /mingw64/libexec/git-core for 64-bit).
Quoted 4 lines
On Linux, when I recompile for a different architecture, CFLAGS would change, so I would have thought that GIT-CFLAGS were the natural choice for a dependency. Don't they change in this case on Windows, too?
Depending on GIT-CFLAGS would have a better chance of being safe, I guess, even though it can at times be overly safe, than GIT-PREFIX, I suspect. As a single user target in Makefile, which is only used by Dscho, who intends to stick to /mingw(32|64)/ convention til the end of time, I think the posted patch is OK, though.
Am 07.11.18 um 02:32 schrieb Junio C Hamano:
Quoted 11 lines
Quoted 4 lines · Johannes Sixt
On Linux, when I recompile for a different architecture, CFLAGS would change, so I would have thought that GIT-CFLAGS were the natural choice for a dependency. Don't they change in this case on Windows, too?
Depending on GIT-CFLAGS would have a better chance of being safe, I guess, even though it can at times be overly safe, than GIT-PREFIX, I suspect. As a single user target in
Makefile, which is only used by Dscho, who intends to stick to /mingw(32|64)/ convention til the end of time, I think the posted patch is OK, though.
I think that it's not only Dscho who uses the target (my build environment, for example, is different from Dscho's and compiles git.res, too). But since the patch helps him most and doesn't hurt others, it is good to go. No objection from my side.
-- Hannes
Quoted 13 lines · Johannes Sixt
Am 07.11.18 um 02:32 schrieb Junio C Hamano:
Quoted 11 lines
Quoted 4 lines · Johannes Sixt
On Linux, when I recompile for a different architecture, CFLAGS would change, so I would have thought that GIT-CFLAGS were the natural choice for a dependency. Don't they change in this case on Windows, too?
Depending on GIT-CFLAGS would have a better chance of being safe, I guess, even though it can at times be overly safe, than GIT-PREFIX, I suspect. As a single user target in
Makefile, which is only used by Dscho, who intends to stick to /mingw(32|64)/ convention til the end of time, I think the posted patch is OK, though.
Quoted 4 lines
I think that it's not only Dscho who uses the target (my build environment, for example, is different from Dscho's and compiles git.res, too). But since the patch helps him most and doesn't hurt others, it is good to go. No objection from my side.
Yeah, that was phrased poorly. What I meant was by "only by Dscho" was "only by those who share the convention that GIT-PREFIX is changed if and only if targetting a different arch".
Anyway, I just wanted to say that GIT-PREFIX may not be precise enough but would give sufficient signal; GIT-CFLAGS may be a more cautious choice, but it may change a bit too often ;-).
Hi,
Quoted 20 lines · Junio C Hamano
Quoted 13 lines · Johannes Sixt
Am 07.11.18 um 02:32 schrieb Junio C Hamano:
Quoted 11 lines
Quoted 4 lines · Johannes Sixt
On Linux, when I recompile for a different architecture, CFLAGS would change, so I would have thought that GIT-CFLAGS were the natural choice for a dependency. Don't they change in this case on Windows, too?
Depending on GIT-CFLAGS would have a better chance of being safe, I guess, even though it can at times be overly safe, than GIT-PREFIX, I suspect. As a single user target in
Makefile, which is only used by Dscho, who intends to stick to /mingw(32|64)/ convention til the end of time, I think the posted patch is OK, though.Quoted 4 lines
I think that it's not only Dscho who uses the target (my build environment, for example, is different from Dscho's and compiles git.res, too). But since the patch helps him most and doesn't hurt others, it is good to go. No objection from my side.
Quoted 7 lines
Yeah, that was phrased poorly. What I meant was by "only by Dscho" was "only by those who share the convention that GIT-PREFIX is changed if and only if targetting a different arch".
Anyway, I just wanted to say that GIT-PREFIX may not be precise enough but would give sufficient signal; GIT-CFLAGS may be a more cautious choice, but it may change a bit too often ;-).
I am fine with GIT-CFLAGS, too. Do you want me to "rick-roll" a v2?
Ciao,
Dscho