[Gambas-user] BSD gambas compile
Tobias Boege
taboege at gmail.com
Fri Jan 1 02:44:22 CET 2021
On Thu, 31 Dec 2020, Bruce Steers wrote:
> Do not fret Tobias.
> I have a knack for looking at things alternatively.
> The double $$ is not something I've used before so issued that line as I
> would have done. I tried a number of other things too till I found the
> issue.
>
> Why? You ask. Lol, I'm sure we've both been at this long enough to know,
> god knows why it works better that way, but it does 😉
>
> And yes I've checked the output trunk_version.h file against original and
> using changes on bsd and linux.
> Tis all good 😇
>
I found my old Raspberry Pi (model B from 2012) and installed FreeBSD on it.
(If you thought your VM was slow...) I can confirm that the current master
branch does not produce trunk_version.h on FreeBSD and that your change
fixes that, but it does so for the wrong reasons :-P
The *reason* for the failure I was asking for is this incompatibility in the
`test` utility between my GNU coreutils on Linux and the FreeBSD version:
gnulinux$ test existing_file -nt nonexisting_file ; echo $?
0
freebsd% test existing_file -nt nonexisting_file ; echo $?
1
Such a check is employed in the make recipe to decide whether to remake
the trunk_version.h file. On FreeBSD, this check passes silently without
creating trunk_version.h. Your change actually breaks the check into always
succeeding because the $GIT_BRANCH variable is evaluated too early -- in
make context, instead of in shell context. Thus the shell command executed
from make checks for the presence of the ../.git/refs/heads/IT_BRANCH file
which does not exist normally. (The $G part of $GIT_BRANCH is evaluated
away to the empty string already in make, because you removed one layer
of dollars. You can observe this by removing the @-silencer from the
trunk_version.h recipe in the generated Makefile.)
This may appear good enough, because the correct data ends up in the correct
header file, but it causes the compiler and interpreter to be partially
recompiled unconditionally every time you recompile Gambas, because the
header file is unconditionally rewritten with the same data every time
you call `make` and hence appears to the build process as if it contains
new data.
My alternative fix is attached. You may want to integrate it into your
patch set of other BSD compile fixes in place of your latest commit.
Or I can apply it to master directly if Benoît agrees.
And a late happy new year from UTC+0100!
Tobias
--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
-------------- next part --------------
>From 0bbd6cb5d273171b4d53662dc1ec377760598c96 Mon Sep 17 00:00:00 2001
From: Tobias Boege <tobias at gambas-buch.de>
Date: Thu, 31 Dec 2020 23:46:44 +0100
Subject: [PATCH] Fix generation of trunk_version.h on BSD
[CONFIGURATION]
* BUG: Do not rely on `test a -nt b` to be true when a exists and b does not. This does not appear to hold true on (Free)BSD.
---
main/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/main/Makefile.am b/main/Makefile.am
index b23d7963a..56e581438 100644
--- a/main/Makefile.am
+++ b/main/Makefile.am
@@ -7,12 +7,12 @@ CLEANFILES = trunk_version.h
.PHONY: trunk_version.h
trunk_version.h:
@if test -d ../.svn ; then \
- if test ../.svn/wc.db -nt trunk_version.h || test ../.svn/entries -nt trunk_version.h; then \
+ if test \! -e trunk_version.h -o ../.svn/wc.db -nt trunk_version.h -o ../.svn/entries -nt trunk_version.h; then \
echo '#define TRUNK_VERSION "'`LC_ALL=C svn info 2>/dev/null | grep Revision | egrep -wo [0-9]+`'"' > trunk_version.h; \
fi \
elif test -d ../.git ; then \
GIT_BRANCH=`git rev-parse --abbrev-ref HEAD`; \
- if test \! -e ../.git/refs/heads/$$GIT_BRANCH -o ../.git/refs/heads/$$GIT_BRANCH -nt trunk_version.h; then \
+ if test \! -e trunk_version.h -o \! -e ../.git/refs/heads/$$GIT_BRANCH -o ../.git/refs/heads/$$GIT_BRANCH -nt trunk_version.h; then \
if GIT_TAG=$$(git describe --exact-match $$GIT_BRANCH 2>/dev/null) ; then \
GIT_BRANCH="$$GIT_TAG"; \
fi; \
--
2.28.0
More information about the User
mailing list