Skip to contentSkip to conversation

perl bindings fix compilation errors

PATCH In review Andy Whitcroft 3 participants 8 messages Jun 15, 2016 Kbuild

lore
Share & tools
lore

Andy Whitcroft

author
#0 lore raw

PATCH 1/1 perl bindings fix compilation errors

perl bindings: fix compilation errors

With the introduction of Makefile.PL to the perl bindings we no longer seem to pass in either the definition of SHA1_HEADER or GIT_VERSION. It seems we no longer pass over the BASIC_FLAGS into the compilation.

Signed-off-by Andy Whitcroft <[email protected]>

---

Makefile +1 -1
index d705e06..d32f4c4 100644
@@ -603,7 +603,7 @@ all: $(ALL_PROGRAMS) $(BUILT_INS) git$X 
 	git-merge-recur$X
 
 all: perl/Makefile
-	$(MAKE) -C perl
+	$(MAKE) -C perl GIT_VERSION='$(GIT_VERSION)' BASIC_CFLAGS="$(BASIC_CFLAGS)"
 	$(MAKE) -C templates
 
 strip: $(PROGRAMS) git$X
perl/Makefile.PL +2 -0
index de73235..00fc779 100644
@@ -5,6 +5,8 @@ sub MY::postamble {
 instlibdir:
 	@echo '$(INSTALLSITELIB)'
 
+CCFLAGS += -DGIT_VERSION='"$(GIT_VERSION)"' $(BASIC_CFLAGS)
+
 MAKE_FRAG
 }
#1 lore raw

Hi,

Quoted 4 lines · Andy Whitcroft

With the introduction of Makefile.PL to the perl bindings we no longer seem to pass in either the definition of SHA1_HEADER or GIT_VERSION. It seems we no longer pass over the BASIC_FLAGS into the compilation.

You probably got bitten by the fact that earlier runs left Git.c in the perl/ directory. Go to perl/, "make distclean", and make git again.

Hth,
Dscho

author
#2 lore raw
Quoted 11 lines · Johannes Schindelin

Hi,

Quoted 4 lines · Andy Whitcroft

With the introduction of Makefile.PL to the perl bindings we no longer seem to pass in either the definition of SHA1_HEADER or GIT_VERSION. It seems we no longer pass over the BASIC_FLAGS into the compilation.

You probably got bitten by the fact that earlier runs left Git.c in the perl/ directory. Go to perl/, "make distclean", and make git again.

Hmmm that sucks. Yes, I had to make distclean more than once, but it seems to fix things.

I am somewhat unhappy that a make clean at the top level and remake was not sufficient to get a working tree.

-apw

#3 lore raw
Quoted 2 lines · Andy Whitcroft

I am somewhat unhappy that a make clean at the top level and remake was not sufficient to get a working tree.

Sympathetic I am (since I was bitten by it too), but I am not sure what the right thing to do.

It is certainly incorrect to say that it is a driver error to git-pull (or git-checkout to switch branches) without running "make clean" first to get rid of perl/Git.c while your Makefile still knows it is a generated file. Our Makefile should be more helpful.

But the question is Makefile in which branch?

Ideally, if Makefile of each and every branch head currently alive knew that perl/Git.c is problematic and removed it, then we would not suffer from this problem. But it's obviously not practical.

#4 lore raw

Hi,

Quoted 5 lines · Junio C Hamano

It is certainly incorrect to say that it is a driver error to git-pull (or git-checkout to switch branches) without running "make clean" first to get rid of perl/Git.c while your Makefile still knows it is a generated file. Our Makefile should be more helpful.

How about this:

Makefile +8 -1
index d3310ae..a722c5a 100644
@@ -612,7 +612,14 @@ ### Build rules
 all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi \
 	git-merge-recur$X
 
-all: perl/Makefile
+# work around for left-over files
+.PHONY: perl/check-left-over
+
+perl/check-left-over:
+	(test -f perl/Git.c && test ! -f perl/Git.xs \
+	 && rm perl/{Git.c,Git.bs,Makefile}) || true
+
+all: perl/check-left-over perl/Makefile
 	$(MAKE) -C perl
 	$(MAKE) -C templates
#5 lore raw
Quoted 11 lines · Johannes Schindelin

Hi,

Quoted 5 lines · Junio C Hamano

It is certainly incorrect to say that it is a driver error to git-pull (or git-checkout to switch branches) without running "make clean" first to get rid of perl/Git.c while your Makefile still knows it is a generated file. Our Makefile should be more helpful.

How about this:

The problem is on which branch we would apply this and how long we will carry it. I suspect you would have to have it forever and everywhere. After all your bisect can hit a version with Git.xs and then next build suggested by bisect may be a version without it. And the user is doing that bisect long after we release version 47.

The worst part is that the version bisect suggests that does not have Git.xs may be a version in the past -- which we obviously cannot apply your patch to.

#6 lore raw

Hi,

Quoted 3 lines · Junio C Hamano

The worst part is that the version bisect suggests that does not have Git.xs may be a version in the past -- which we obviously cannot apply your patch to.

Okay, just forget about my patch.

Ciao,
Dscho

#7 lore raw
In reply to Andy Whitcroft

Hi,

Quoted 10 lines · Andy Whitcroft
Quoted 9 lines · Johannes Schindelin

Hi,

Quoted 4 lines · Andy Whitcroft

With the introduction of Makefile.PL to the perl bindings we no longer seem to pass in either the definition of SHA1_HEADER or GIT_VERSION. It seems we no longer pass over the BASIC_FLAGS into the compilation.

Quoted 8 lines
Quoted 2 lines

You probably got bitten by the fact that earlier runs left Git.c in the perl/ directory. Go to perl/, "make distclean", and make git again.

Hmmm that sucks. Yes, I had to make distclean more than once, but it seems to fix things.

I am somewhat unhappy that a make clean at the top level and remake was not sufficient to get a working tree.

Yes. I almost submitted a patch which checks for perl/Git.c, and makes distclean in perl/ if exists.

Ciao,
Dscho