Hi Akim. On Wed, 12 Aug 2009, Akim Demaille wrote:
> Le 4 août 09 à 22:31, Joel E. Denny a écrit : > > > I pushed this to branch-2.4.2, branch-2.5, and master. > > I also needed the following. I don't understand why you didn't: there was no > reason for the stamp file to be shipped, so it should be created during the > "make" step of distcheck, and it should fail since it tries to write in the > srcdir, which is readonly at that moment. > > From 67af719840616ed07ca120b8255a998f4533ce17 Mon Sep 17 00:00:00 2001 > From: Akim Demaille <[email protected]> > Date: Wed, 1 Jul 2009 12:19:18 +0200 > Subject: [PATCH] distcheck: fix. > > * examples/calc++/Makefile.am: (EXTRA_DIST): Ship calc.stamp. That makes sense to me, but I didn't think of it when I wrote my patch, and, at that time, I didn't experience the problem that your patch should fix. If I'm understanding the situation, the explanation is ugly.... I just checked out the current master, commit 28169bab1f6f2fc9d682118703f6267c63583720, and manually removed calc.stamp from EXTRA_DIST. "make distcheck" gets past the calc.stamp problem it encountered before my patch, and I agree it shouldn't. Later, it runs into a different problem, so I decided to ignore master during the rest of my experiments. I then tried "make distcheck" on commits 98744608198dbc3f5025432c576aa009f7f8c174 and 36dfe4662ef5eb96073034b9eb80113b0c2a204e, which immediately precede your above patch on branch-2.4.2 and branch-2.5, respectively. In both cases, "make distcheck" succeeds. Again, I agree it shouldn't. I then tried building from the tarball generated by "make dist" so I could see how calc.stamp is used: % cd ~/bison.git % git checkout 36dfe4662ef5eb96073034b9eb80113b0c2a204e % ./bootstrap && ./configure && make && make dist % tar xvfj bison-2.4.1.108-36df.tar.bz2 % cd bison-2.4.1.108-36df % find . -name calc.stamp # nothing found % mkdir _build && cd _build % ../configure && make # it did not run the calc.stamp target rule % cd .. % find . -name calc.stamp # nothing found That didn't make sense to me, so I tried again. This time, I first removed the calc.stamp in my bison.git, which obviously isn't supposed to affect the results, but it's the only calc.stamp lying around: % cd ~/bison.git % rm examples/calc++/calc.stamp % rm -r bison-2.4.1.108-36df % tar xvfj bison-2.4.1.108-36df.tar.bz2 % cd bison-2.4.1.108-36df % find . -name calc.stamp # nothing found % mkdir _build && cd _build % ../configure && make # it *did* run the calc.stamp target rule % cd .. % find . -name calc.stamp ./examples/calc++/calc.stamp Smells like VPATH: % pwd /home/jdenny/bison.git/bison-2.4.1.108-36df % grep VPATH examples/calc++/Makefile.am # nothing found % grep VPATH examples/calc++/Makefile.in VPATH = @srcdir@ % grep VPATH _build/examples/calc++/Makefile VPATH = ../../../examples/calc++ % grep calc.stamp examples/calc++/Makefile.am $(srcdir)/calc.stamp: $(doc) $(extexi) $(calc_extracted): $(srcdir)/calc.stamp % grep '\<srcdir =' _build/examples/calc++/Makefile srcdir = ../../../examples/calc++ At the shell prompt, I then assigned VPATH and srcdir to the values extracted above. I then checked how make might try to resolve $(srcdir)/calc.stamp from its build directory: % pwd /home/jdenny/bison.git/bison-2.4.1.108-36df % cd _build/examples/calc++ % cd $VPATH/$srcdir % pwd /home/jdenny/bison.git/examples/calc++ So @srcdir@/$(srcdir) backs up two levels in the following hierarchy of directories but stays within examples/calc++/ in each level: bison.git/bison-2.4.1.108-36df/_build It guess that means "make distcheck" has a limitation for my usage. One possible fix would be for "make distcheck" to make the hierarchy look like this instead: bison.git/distcheck.tmp/bison-2.4.1.108-36df/_build @srcdir@/$(srcdir) would still back up two levels, but it would not find an examples/calc++/ there. I'm now trying to think of ways to reproduce the behavior you saw. I assume you didn't manually remove calc.stamp from your bison.git. Are you separating the src and build directories even for your bison.git? For example: % cd ~/bison.git && git clean -dfx && ./bootstrap % mkdir ~/bison.git-build && cd ~/bison.git-build % ~/bison.git/configure && make && make distcheck If so, then calc.stamp would no longer be two levels up, so "make distcheck" would fail as expected. (It still seems a little dirty that bison.git-build is two levels up. I think it might confuse some other distcheck issue one day.) In case your src and build directories for your bison.git were actually the same like mine, here's some information about my system: % automake --version | grep automake automake (GNU automake) 1.10.1 % make --version |grep Make GNU Make 3.81 % autoconf --version |grep autoconf autoconf (GNU Autoconf) 2.63 What are your versions? I'm expecting that we'll eventually reach at least one of the following conclusions: 1. My build habits are wrong for automake. 2. I need to update my automake. 3. automake has a distcheck limitation that we should report. It seems there's a simple fix: it should push the distro directory down another level.
