Re: sysconf_DATA v. dist_sysconf_DATA
Hi Stepan, * Stepan Kasal wrote on Tue, Dec 05, 2006 at 07:34:48PM CET: * lib/am/distdir.am (distcheck): Move the srcdir below `$(distdir)/_dist', so that `_build' and `_inst' are not below it. * tests/insthook.test: Do not depend on the actual implementation of `distcheck'. FWIW, this looks good to me, thanks. I'll put it on the list. Cheers, Ralf
Re: sysconf_DATA v. dist_sysconf_DATA
Hello Ralf and all,
[sorry for the delay, I forgot this in my postponed folder]
On Fri, Nov 10, 2006 at 01:35:54PM +0100, Ralf Wildenhues wrote:
* Stepan Kasal wrote on Fri, Nov 10, 2006 at 12:40:18PM CET:
[...] So it seems that distcheck would
catch more bugs if `_build' were not a subdirectory of the expanded
tarball tree.
It would possibly catch a different set of bugs. There isn't a strict
inclusion ordering on the set of all imaginable bugs; maybe if bugs are
weighted by the likelihood by which they happen, I haven't looked into
that enough.
When srcdir is .. (or ../.. or some such), it represents a
relative path which is valid in many places.
So it is possible that the relative path would be applied to a wrong
place, probably because of the VPATH mechanism.
This can mask an error, as we observed in this thread.
OTOH, this could discover another type of error in the build scripts
of the package; I cannot imagine an actual example, but I admit it is
possible.
But I think that the former case is more common, and thus the
disadvantage overweight the advantage.
If the srcdir is ../_dist/$(distdir) or some such, it is not
probable that it would apply relatively to a wrong directory.
Would you accept the patch attached below?
Stepan Kasal
2006-12-05 Stepan Kasal [EMAIL PROTECTED]
* lib/am/distdir.am (distcheck): Move the srcdir below
`$(distdir)/_dist', so that `_build' and `_inst' are not
below it.
* tests/insthook.test: Do not depend on the actual
implementation of `distcheck'.
Index: lib/am/distdir.am
===
RCS file: /cvs/automake/automake/lib/am/distdir.am,v
retrieving revision 1.69
diff -u -r1.69 distdir.am
--- lib/am/distdir.am 15 Oct 2006 16:37:22 - 1.69
+++ lib/am/distdir.am 5 Dec 2006 18:31:05 -
@@ -315,26 +315,25 @@
# tarfile.
.PHONY: distcheck
distcheck: dist
- case '$(DIST_ARCHIVES)' in \
+ mkdir $(distdir)
+ mkdir $(distdir)/_dist
+ $(am__cd) $(distdir)/_dist case '$(DIST_ARCHIVES)' in \
*.tar.gz*) \
- GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz | $(am__untar) ;;\
+ GZIP=$(GZIP_ENV) gunzip -c ../../$(distdir).tar.gz | $(am__untar) ;;\
*.tar.bz2*) \
- bunzip2 -c $(distdir).tar.bz2 | $(am__untar) ;;\
+ bunzip2 -c ../../$(distdir).tar.bz2 | $(am__untar) ;;\
*.tar.Z*) \
- uncompress -c $(distdir).tar.Z | $(am__untar) ;;\
+ uncompress -c ../../$(distdir).tar.Z | $(am__untar) ;;\
*.shar.gz*) \
- GZIP=$(GZIP_ENV) gunzip -c $(distdir).shar.gz | unshar ;;\
+ GZIP=$(GZIP_ENV) gunzip -c ../../$(distdir).shar.gz | unshar ;;\
*.zip*) \
- unzip $(distdir).zip ;;\
+ unzip ../../$(distdir).zip ;;\
esac
## Make the new source tree read-only. Distributions ought to work in
-## this case. However, make the top-level directory writable so we
-## can make our new subdirs.
- chmod -R a-w $(distdir); chmod a+w $(distdir)
+## this case.
+ chmod -R a-w $(distdir)/_dist
mkdir $(distdir)/_build
mkdir $(distdir)/_inst
-## Undo the write access.
- chmod a-w $(distdir)
## Compute the absolute path of `_inst'. Strip any leading DOS drive
## to allow DESTDIR installations. Otherwise $(DESTDIR)$(prefix) would
## expand to c:/temp/am-dc-5668/c:/src/package/package-1.0/_inst.
@@ -344,8 +343,8 @@
## create very long directory names.
dc_destdir=$${TMPDIR-/tmp}/am-dc-/ \
?DISTCHECK-HOOK? $(MAKE) $(AM_MAKEFLAGS) distcheck-hook \
- cd $(distdir)/_build \
- ../configure --srcdir=.. --prefix=$$dc_install_base \
+ $(am__cd) $(distdir)/_build \
+ ../_dist/$(distdir)/configure --srcdir=../_dist/$(distdir)
--prefix=$$dc_install_base \
?GETTEXT? --with-included-gettext \
## Additional flags for configure. Keep this last in the configure
## invocation so the user can override previous options.
Index: tests/insthook.test
===
RCS file: /cvs/automake/automake/tests/insthook.test,v
retrieving revision 1.12
diff -u -r1.12 insthook.test
--- tests/insthook.test 14 May 2005 20:28:55 - 1.12
+++ tests/insthook.test 5 Dec 2006 18:31:06 -
@@ -40,7 +40,7 @@
installcheck-local:
test -f $(bindir)/foo
test -f $(bindir)/foo-$(VERSION)
- : $(top_srcdir)/../ok
+ test -n $$stampdir : $$stampdir/ok
END
echo 1 foo
@@ -50,7 +50,7 @@
$AUTOMAKE
./configure
-$MAKE distcheck
+stampdir=`pwd` $MAKE -e distcheck
# Sanity check to make sure installcheck-local was run.
test -f ok
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Fri, Nov 10, 2006 at 11:27:18AM -0700, David Everly wrote: I have been working to follow this. It seems however that I need dist_TESTS, but this seems to not work so perhaps I should do this instead: EXTRA_DIST = $(TESTS) yes, that is fine. One nit about style: I would rather use dist_check_SCRIPTS = $(TESTS) Or perhaps the other way round. Let me give a more general example; perhaps some of the tests are compiled programs, some are built stripts and some are distributed scripts. Then you would have: check_PROGRAMS = foo bar foo_SOURCES = foo.c bar_SOURCES = bar.c baz.c nodist_check_SCRIPTS = this # this is created from this.in by configure dist_check_SCRIPTS = that another TESTS = $(check_PROGRAMS) $(nodist_check_SCRIPTS) $(dist_check_SCRIPTS) Have a nice day, Stepan Kasal
Re: sysconf_DATA v. dist_sysconf_DATA
* Stepan Kasal wrote on Fri, Nov 10, 2006 at 12:40:18PM CET: On Thu, Nov 09, 2006 at 02:04:20PM +0100, Ralf Wildenhues wrote: http://lists.gnu.org/archive/html/automake/2006-09/msg00014.html indeed, very interesting read. So it seems that distcheck would catch more bugs if `_build' were not a subdirectory of the expanded tarball tree. It would possibly catch a different set of bugs. There isn't a strict inclusion ordering on the set of all imaginable bugs; maybe if bugs are weighted by the likelihood by which they happen, I haven't looked into that enough. But I think you used ../configure No. _I_ called ./configure. It was `make distcheck' who called ../configure, which then led to the above message. Ah, but then that means you didn't even create the file test.txt in the first place (and looking back at your description, you did not state this, so ok). A simple make would have caught that, though, so your example then would not have exposed the error that David reported. Cheers, Ralf
Re: sysconf_DATA v. dist_sysconf_DATA
On 11/9/06, Stepan Kasal [EMAIL PROTECTED] wrote: Hello, On Thu, Nov 09, 2006 at 06:30:42AM -0700, David Everly wrote: If I understand this correctly, my error was in the use of $(top_srcdir). So I'm wondering under what circumstances it would be correct to use $(top_srcdir) and $(srcdir). a very quick answer: do not use $(top_srcdir) nor $(srcdir). (I apologize that I have not noticed this earlier.) In variables interpreted by Automake (like sysconf_DATA), the $(srcdir) prefix is not needed. It is possible that new versions of Automake were patched to delete it, but it does not belong there. To enhance the above advice: do not use $(srcdir) (and such) until you encounter a problem which will force you to use them. And I think that when you are forced to use $(srcdir) in Makefile.am, it'll be in a _rule_, not in a variable. This is just a rule of thumb, it is possible that others will correct/amend it. I have been working to follow this. It seems however that I need dist_TESTS, but this seems to not work so perhaps I should do this instead: EXTRA_DIST = $(TESTS)
Re: sysconf_DATA v. dist_sysconf_DATA
Hello David, * David Everly wrote on Thu, Nov 09, 2006 at 01:46:23AM CET: I put together a test case before sending my email, the only line in the one Makefile.am is the one I gave containing test.txt. So, where is it? Please send it, so the guessing has an end. Cheers, Ralf
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Wed, Nov 08, 2006 at 05:46:23PM -0700, David Everly wrote: I put together a test case before sending my email, the only line in the one Makefile.am is the one I gave containing test.txt. well, I created configure.ac and Makefile.am: $ cat configure.ac AC_INIT([this], [1.0], [EMAIL PROTECTED]) AM_INIT_AUTOMAKE([foreign]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT $ cat Makefile.am sysconf_DATA = $(top_srcdir)/test.txt $ Then I run: autoreconf -i ./configure make distcheck and the distcheck failed with the expected message: make[1]: *** No rule to make target `../test.txt', needed by `all-am'. Stop. I used recent CVS build of Autoconf, and a CVS version of Automake which is slightly older than 1.10. Stepan
Re: sysconf_DATA v. dist_sysconf_DATA
On 11/9/06, Stepan Kasal [EMAIL PROTECTED] wrote: Hello, On Wed, Nov 08, 2006 at 05:46:23PM -0700, David Everly wrote: I put together a test case before sending my email, the only line in the one Makefile.am is the one I gave containing test.txt. well, I created configure.ac and Makefile.am: $ cat configure.ac AC_INIT([this], [1.0], [EMAIL PROTECTED]) AM_INIT_AUTOMAKE([foreign]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT $ cat Makefile.am sysconf_DATA = $(top_srcdir)/test.txt $ Then I run: autoreconf -i ./configure make distcheck This is almost identical to what I tried. and the distcheck failed with the expected message: make[1]: *** No rule to make target `../test.txt', needed by `all-am'. Stop. I used recent CVS build of Autoconf, and a CVS version of Automake which is slightly older than 1.10. Ok, so there must be something that is better about CVS because your test also does not fail for me.
Re: sysconf_DATA v. dist_sysconf_DATA
On 11/9/06, David Everly [EMAIL PROTECTED] wrote: On 11/9/06, Stepan Kasal [EMAIL PROTECTED] wrote: On Wed, Nov 08, 2006 at 05:46:23PM -0700, David Everly wrote: and the distcheck failed with the expected message: make[1]: *** No rule to make target `../test.txt', needed by `all-am'. Stop. I used recent CVS build of Autoconf, and a CVS version of Automake which is slightly older than 1.10. Ok, so there must be something that is better about CVS because your test also does not fail for me. I just noticed there is Automake 1.10 (I'm using 1.9.6). I'll try 1.10 and report back.
Re: sysconf_DATA v. dist_sysconf_DATA
* David Everly wrote on Thu, Nov 09, 2006 at 01:52:12PM CET: On 11/9/06, Stepan Kasal [EMAIL PROTECTED] wrote: On Wed, Nov 08, 2006 at 05:46:23PM -0700, David Everly wrote: I put together a test case before sending my email, the only line in the one Makefile.am is the one I gave containing test.txt. well, I created configure.ac and Makefile.am: [...] This is almost identical to what I tried. Thanks for the example. So this is the same issue as discussed in this thread: http://lists.gnu.org/archive/html/automake/2006-09/msg00014.html and the distcheck failed with the expected message: make[1]: *** No rule to make target `../test.txt', needed by `all-am'. Stop. Stepan, I don't think you did exactly as you wrote. You wrote: Then I run: autoreconf -i ./configure make distcheck But I think you used ../configure instead. I used recent CVS build of Autoconf, and a CVS version of Automake which is slightly older than 1.10. Ok, so there must be something that is better about CVS because your test also does not fail for me. Nope. Cheers, Ralf
Re: sysconf_DATA v. dist_sysconf_DATA
On 11/9/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: * David Everly wrote on Thu, Nov 09, 2006 at 01:52:12PM CET: On 11/9/06, Stepan Kasal [EMAIL PROTECTED] wrote: On Wed, Nov 08, 2006 at 05:46:23PM -0700, David Everly wrote: I put together a test case before sending my email, the only line in the one Makefile.am is the one I gave containing test.txt. well, I created configure.ac and Makefile.am: [...] This is almost identical to what I tried. Thanks for the example. So this is the same issue as discussed in this thread: http://lists.gnu.org/archive/html/automake/2006-09/msg00014.html If I understand this correctly, my error was in the use of $(top_srcdir). So I'm wondering under what circumstances it would be correct to use $(top_srcdir) and $(srcdir). Or is it that I should 'make distcheck' from a VPATH build? Either of these two approaches seem to address my issue. Is one more correct than the other?
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Thu, Nov 09, 2006 at 06:30:42AM -0700, David Everly wrote: If I understand this correctly, my error was in the use of $(top_srcdir). So I'm wondering under what circumstances it would be correct to use $(top_srcdir) and $(srcdir). a very quick answer: do not use $(top_srcdir) nor $(srcdir). (I apologize that I have not noticed this earlier.) In variables interpreted by Automake (like sysconf_DATA), the $(srcdir) prefix is not needed. It is possible that new versions of Automake were patched to delete it, but it does not belong there. To enhance the above advice: do not use $(srcdir) (and such) until you encounter a problem which will force you to use them. And I think that when you are forced to use $(srcdir) in Makefile.am, it'll be in a _rule_, not in a variable. This is just a rule of thumb, it is possible that others will correct/amend it. HTH, Stepan Kasal
Re: sysconf_DATA v. dist_sysconf_DATA
Thanks for the helpful advice, this is now working for me. On 11/9/06, Stepan Kasal [EMAIL PROTECTED] wrote: Hello, On Thu, Nov 09, 2006 at 06:30:42AM -0700, David Everly wrote: If I understand this correctly, my error was in the use of $(top_srcdir). So I'm wondering under what circumstances it would be correct to use $(top_srcdir) and $(srcdir). a very quick answer: do not use $(top_srcdir) nor $(srcdir). (I apologize that I have not noticed this earlier.) In variables interpreted by Automake (like sysconf_DATA), the $(srcdir) prefix is not needed. It is possible that new versions of Automake were patched to delete it, but it does not belong there. To enhance the above advice: do not use $(srcdir) (and such) until you encounter a problem which will force you to use them. And I think that when you are forced to use $(srcdir) in Makefile.am, it'll be in a _rule_, not in a variable. This is just a rule of thumb, it is possible that others will correct/amend it. HTH, Stepan Kasal -- ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html
sysconf_DATA v. dist_sysconf_DATA
automake (GNU automake) 1.9.6 autoconf (GNU Autoconf) 2.60 HP-UX omztdv1 B.11.23 U ia64 I have recently discovered this in the manual: By default, data files are not included in a distribution. Of course, you can use the dist_ prefix to change this on a per-variable basis. So instead of this in Makefile.am: sysconf_DATA = $(top_srcdir)/test.txt I should have used this (because test.txt is not constructed): dist_sysconf_DATA = $(top_srcdir)/test.txt However, I've regularly run 'make distcheck' and it gives no error with the original sysconf_DATA. How can this be?
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Wed, Nov 08, 2006 at 11:29:39AM -0700, David Everly wrote: I should have used this (because test.txt is not constructed): dist_sysconf_DATA = $(top_srcdir)/test.txt However, I've regularly run 'make distcheck' and it gives no error with the original sysconf_DATA. How can this be? `make distcheck' creates a tarball, unpacks it to a new directory and runs build and install there. This implies that test.txt was installed during the process. So it seems it was available. When you run `make dist' with the old setup, is test.txt packed in the resulting tarball? Perhaps the file was mentioned in EXTRA_DIST, or another list of distributed files. In that case it would not be strictly necessary to use `dist_sysconf_DATA' instead of `sysconf_DATA'. But in most cases, it is more readable to use `dist_sysconf_DATA'. HTH, Stepan
Re: sysconf_DATA v. dist_sysconf_DATA
On 11/8/06, Stepan Kasal [EMAIL PROTECTED] wrote: Hello, On Wed, Nov 08, 2006 at 11:29:39AM -0700, David Everly wrote: I should have used this (because test.txt is not constructed): dist_sysconf_DATA = $(top_srcdir)/test.txt However, I've regularly run 'make distcheck' and it gives no error with the original sysconf_DATA. How can this be? `make distcheck' creates a tarball, unpacks it to a new directory and runs build and install there. This implies that test.txt was installed during the process. So it seems it was available. When you run `make dist' with the old setup, is test.txt packed in the resulting tarball? This is the curious part, test.txt is _not_ packed in the resulting tarball, and if I run configure, make install directly it fails. Perhaps the file was mentioned in EXTRA_DIST, or another list of distributed files. In that case it would not be strictly necessary to use `dist_sysconf_DATA' instead of `sysconf_DATA'. I put together a test case before sending my email, the only line in the one Makefile.am is the one I gave containing test.txt. But in most cases, it is more readable to use `dist_sysconf_DATA'. I have no issue using `dist_sysconf_DATA', but I was hoping not to have to do a separate build on the resulting tarball beyond what make distcheck does, so I could find other such errors.
