Re: dvi bug in distcheck target?
* John Calcote wrote on Wed, Jun 24, 2009 at 09:15:10PM CEST: > It never occurred to me that Automake would > look inside the texi file to determine the name of the output file, > but it makes sense. I don't think it does. Well, maybe it produces "expected results" for a large number of use cases, but every time the output of automake depends upon the contents (or even existence) of other files, we have dependency issues and are liable for surprises: strictly speaking, in this case, Makefile.in should depend upon the .texi file, and thus be regenerated each time the .texi file changes. However, that would certainly not be expected by automake users just writing on their manual a bit. Cheers, Ralf
Re: dvi bug in distcheck target?
Hi Ralf, On 6/24/2009 12:59 PM, Ralf Wildenhues wrote: It looks like the last line should contain: zardoz.dvi zardoz.pdf zardoz.ps zardoz.html It would if you had @setfilename zardoz.info in your zardoz.texi file. Hmm, this is probably a bug in Automake, but from 'info texi2dvi', I cannot even infer whether it is intentional that @setfilename not decide the name of DVI or PDF output, and while I think it implies to do so for HTML, I'm not fully sure either. Wow. Sure enough. I set the texi setfilename field to zardoz.info and all is well again. It never occurred to me that Automake would look inside the texi file to determine the name of the output file, but it makes sense. I copied this sample file from the texinfo manual as a quick input file, but didn't check the contents that closely. Thanks for the tip. John
Re: dvi bug in distcheck target?
Hi John, thanks for the report. * John Calcote wrote on Wed, Jun 24, 2009 at 08:10:02PM CEST: > It appears that make clean is leaving the dvi file in place. In > fact, when I manually execute make clean, after make dvi, I get the > following output: > > test -z "zardoz" || rm -f zardoz > rm -rf zardoz.aux zardoz.cp zardoz.cps zardoz.fn zardoz.fns zardoz.ky \ > zardoz.kys zardoz.log zardoz.pg zardoz.pgs zardoz.tmp \ > zardoz.toc zardoz.tp zardoz.tps zardoz.vr zardoz.vrs \ > sample.dvi sample.pdf sample.ps sample.html > rm -f *.o > > It looks like the last line should contain: > > zardoz.dvi zardoz.pdf zardoz.ps zardoz.html It would if you had @setfilename zardoz.info in your zardoz.texi file. Hmm, this is probably a bug in Automake, but from 'info texi2dvi', I cannot even infer whether it is intentional that @setfilename not decide the name of DVI or PDF output, and while I think it implies to do so for HTML, I'm not fully sure either. Cheers, Ralf
dvi bug in distcheck target?
Hi Automake maintainers, I think there's a bug in the distcheck target related to the TEXINFO primary. (You may already know about it. I did a google search, but didn't find any references to it.) Here's part of a sample Makefile.am from page 24 of the the Automake manual (1.10.2): bin_PROGRAMS = zardoz zardoz_SOURCES = main.c info_TEXINFOS = zardoz.texi Combined with a simple configure.ac file, when I run "make distcheck", I get the following error: ... ERROR: files left in build directory after distclean: ./zardoz.dvi make[1]: *** [distcleancheck] Error 1 make[1]: Leaving directory `/home/jcalcote/dev/prj/ti-test/zardoz-1.0/_build' make: *** [distcheck] Error 2 $ I have to add this line to the Makefile.am file to get the distcheck target to work cleanly: CLEANFILES = zardoz.dvi It appears that make clean is leaving the dvi file in place. In fact, when I manually execute make clean, after make dvi, I get the following output: test -z "zardoz" || rm -f zardoz rm -rf zardoz.aux zardoz.cp zardoz.cps zardoz.fn zardoz.fns zardoz.ky \ zardoz.kys zardoz.log zardoz.pg zardoz.pgs zardoz.tmp \ zardoz.toc zardoz.tp zardoz.tps zardoz.vr zardoz.vrs \ sample.dvi sample.pdf sample.ps sample.html rm -f *.o It looks like the last line should contain: zardoz.dvi zardoz.pdf zardoz.ps zardoz.html Regards, John
Re: Bug in "distcheck" target?
Pavel Roskin wrote: > > Hello! > At some point, "make distcheck" would simply call "make dist" and run the > standalone "distcheck" script with predefined DISTCHECK_FLAGS. YES!
Re: Bug in "distcheck" target?
Hello! It has occured to me that the complex "distcheck" procedure doesn't have to be integrated into Automake. In fact, "make distcheck" works with the tarball and treats it as a black box. Automake knows a lot about most of the files and can generate rules that work with those files. But the whole idea of "make distcheck" it to make sure that the whole package behaves properly, including the custom rules not generated by Automake. I believe that a separate program for testing packages would be a much more flexible solution. You would be able to get a package from the net and check if that package behaves good, i.e. that it doesn't try to run autoconf or automake, respects DESTDIR and prefix, has all standard targets, passes "make check" and so on. You could use a new distcheck script on old packages. You would not have to run automake on it, and you would test the package as is, not what it would become after upgrading to the latest and greatest automake. The script could even produce a report about properties of the package (i.e. whether prefix and DESTDIR affect all files, passed make targets, failed make targets etc). I'm not saying that "make distcheck" support should be dropped from Automake any time soon, but having a standalone script would reduce the need in making "make distcheck" more and more complex, and especially the need in introducing any new Automake options affecting strictness of "make distcheck". At some point, "make distcheck" would simply call "make dist" and run the standalone "distcheck" script with predefined DISTCHECK_FLAGS. -- Regards, Pavel Roskin
Re: Bug in "distcheck" target?
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> >>> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes:
>
> [...]
>
> Roger> However, this makes one very big assumption: every
> Roger> installation directory will use $prefix as the path
> Roger> prefix.
>
> Yes. This way we make sure people can install the package with
> --prefix=/usr, --prefix=/opt, --prefix ~/usr, or whatever.
You could use /both/ --prefix= and DESTDIR= to ensure that the package
works with --prefix and then still set DESTDIR so that rules that
don't (can't) use $(prefix) will still get installed into =inst. BTW,
setting DESTDIR could also ensure that the package also respects
DESTDIR, by making sure that no data is installed into $(prefix),
because $(prefix) will be $(DESTDIR)$(prefix). Packages that
inconsistently handle DESTDIR are really annoying, possibly because
people don't even realise it exists.
You could set dc_prefix_base=`$(am__cd) $(distdir)/=error && pwd`
and use --prefix=$$dc_prefix_base and DESTDIR=$$dc_install_base:
--- am-distcheckThu Sep 19 21:54:37 2002
+++ am-distcheck.newThu Sep 19 22:04:19 2002
@@ -6,19 +6,25 @@
GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz | $(AMTAR) xf -
chmod -R a-w $(distdir); chmod a+w $(distdir)
mkdir $(distdir)/=build
+ mkdir $(distdir)/=error
mkdir $(distdir)/=inst
chmod a-w $(distdir)
+ dc_prefix_base=`$(am__cd) $(distdir)/=error && pwd` \
dc_install_base=`$(am__cd) $(distdir)/=inst && pwd` \
&& cd $(distdir)/=build \
- && ../configure --srcdir=.. --prefix=$$dc_install_base \
+ && ../configure --srcdir=.. --prefix=$$dc_prefix_base \
--with-included-gettext \
$(DISTCHECK_CONFIGURE_FLAGS) \
&& $(MAKE) $(AM_MAKEFLAGS) \
&& $(MAKE) $(AM_MAKEFLAGS) dvi \
&& $(MAKE) $(AM_MAKEFLAGS) check \
- && $(MAKE) $(AM_MAKEFLAGS) install \
- && $(MAKE) $(AM_MAKEFLAGS) installcheck \
- && $(MAKE) $(AM_MAKEFLAGS) uninstall \
+ && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \
+ && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \
+ && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \
+ && (test `find $$dc_prefix_base -type f -print | wc -l` -le 1 \
+ || { echo "ERROR: files and directories not installed into DESTDIR:" ; \
+ find $$dc_prefix_base -print ; \
+ exit 1; } >&2 ) \
&& (test `find $$dc_install_base -type f -print | wc -l` -le 1 \
|| { echo "ERROR: files left after uninstall:" ; \
find $$dc_install_base -type f -print ; \
> Roger> This is usually the case, but not always. For example,
> Roger> in the gimp-print project, we build a CUPS driver. For
> Roger> this, the install path is obtained from "cups-config",
>
> How about you honor the user's flags, and just issue a warning
> if it's different from the output of cups-config?
The user never gets a say. I have in my Makefile.am something like:
if BUILD_GIMP
gimp_plug_in_PROGRAMS = print
endif
and in configure.ac, I have a custom autoconf macro
STP_GIMP_PLUG_IN_DIR which extracts gimp_plug_indir from "gimptool".
Another macro gets the "foomatic" data directory location, too.
I have a similar arrangement for CUPS, with the exception that
--enable-cups will accept a prefix as well as yes or no. cups-config
(if present) overrides the users preference, since its information is
definitive.
In all three cases, the path should never need to be set by the user,
and is something like "cupsexec_filterdir = $(pkglibdir)/filter" where
pkglibdir is `cups-config --datadir`. There is no way of tacking a
$prefix on to these, especially for the GIMP and foomatic data, where
it is /always/ automatic, and adding an override would only ever be
used with "make distcheck", and I would rather not write more m4
(there's already > 50 kB of my own custom macros) just to work around
automake.
> Another idea is the have a --without-cups-config option that you
> will set in DISTCHECK_CONFIGURE_FLAGS.
This is already possible--for cups, but it would require a separate
option for every other driver (CUPS is just one example).
> [...]
>
> Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \
> Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \
> Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \
>
> Unfortunately `make installcheck' isn't expected to run in a
> DESTDIR installation as it might run programs which read files
> using the real $prefix.
I have looked at the generated Makefile.ins under 1.5 and 1.6.3, and I
can't see installcheck being used (except empty rules/for recursion).
Surely any user who wrote an installcheck-local target could use
$(prefix) and $(DESTDIR)$(prefix) as required to distinguish between
the intended and actual destinatio
Re: Bug in "distcheck" target?
Hello! > Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \ > Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \ > Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \ > > Unfortunately `make installcheck' isn't expected to run in a > DESTDIR installation as it might run programs which read files > using the real $prefix. Let's make an option (that would go to AUTOMAKE_OPTIONS) to enable relaxed check using DESTDIR. `make installcheck' would be skipped if this option is used. For example, reiserfsprogs installs binaries to /sbin, and they has a good reason for that. Using DESTDIR is the only way that reiserfsprogs passes `make distcheck'. It's still better than `make dist' for making real releases. -- Regards, Pavel Roskin
Re: Bug in "distcheck" target?
>>> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes: [...] Roger> However, this makes one very big assumption: every Roger> installation directory will use $prefix as the path Roger> prefix. Yes. This way we make sure people can install the package with --prefix=/usr, --prefix=/opt, --prefix ~/usr, or whatever. Roger> This is usually the case, but not always. For example, Roger> in the gimp-print project, we build a CUPS driver. For Roger> this, the install path is obtained from "cups-config", How about you honor the user's flags, and just issue a warning if it's different from the output of cups-config? Another idea is the have a --without-cups-config option that you will set in DISTCHECK_CONFIGURE_FLAGS. [...] Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \ Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \ Roger> && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \ Unfortunately `make installcheck' isn't expected to run in a DESTDIR installation as it might run programs which read files using the real $prefix. [...] -- Alexandre Duret-Lutz
Bug in "distcheck" target?
I recently found a bug in the distcheck target: dc_install_base=`$(am__cd) $(distdir)/=inst && pwd` \ && cd $(distdir)/=build \ && ../configure --srcdir=.. --prefix=$$dc_install_base \ ^^ --with-included-gettext \ $(DISTCHECK_CONFIGURE_FLAGS) \ I don't know if this will be considered buggy behaviour. However, this makes one very big assumption: every installation directory will use $prefix as the path prefix. This is usually the case, but not always. For example, in the gimp-print project, we build a CUPS driver. For this, the install path is obtained from "cups-config", because the CUPS package is completely independent. This path will never contain $prefix, and so make distcheck will always fail. Suggested fix: Even though in this case, setting $prefix will not work, a similar effect could be achieved by setting "DESTDIR=$$dc_install_base" when installing and uninstalling. Every installed object should respect DESTDIR, and so this would not break distcheck. Modifying the distcheck rule as follows, and removing the --prefix option works fine: && $(MAKE) $(AM_MAKEFLAGS) install \ && $(MAKE) $(AM_MAKEFLAGS) installcheck \ && $(MAKE) $(AM_MAKEFLAGS) uninstall \ becomes && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \ && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \ && $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \ My current workaround is a new configure option, --enable-non-native-install-prefix=PREFIX, which is blank by default. This is used in install-*-local to install into $(DESTDIR)$(non_native_install_prefix)$(installdir), but this is totally gross. Currently I test the build with make DESTDIR=/tmp/test install # check everything is installed make DESTDIR=/tmp/test uninstall # check everything is cleaned up due to distcheck not working. Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
