On Sunday 26 November 2000 20:40, Steve Robbins wrote: > 1. Automake inserts a makefile variable "TAR" into every Makefile.in > generated. Upstream has "TAR = gtar", but I have "TAR = tar", greatly > (and needlessly) inflating the .diff. The value of TAR is hardcoded into > automake itself.
I don't believe it. I think a variable "TAR" is defined in Makefile.am. > > 2. I patch configure.in, so after "dpkg-source -x ...", timestamps on > various files may be messed up, triggering makefile rules to rebuild > configure or Makefile.in, etc. [If you've ever built an automake'ified > project, you'll know what I'm talking about.] > > Unfortunately, one of the things run is "aclocal", but without the > necessary "-I m4" flag, causing the build to fail. [Amusingly, the build > would work if automake was not installed, because the "missing" script > will just touch the files to get the timestamps in the right order.] In this case aclocal needs macros from other *.m4 file than aclocal.m4. These additional files *should* be in upstream sources, if not try to contact with upstream authors(s). > In light of the above, one solution that suggests itself is to just stick > autoconf and automake in the Build-depends line, and automake is enough, I think so. > 1. run "make maintainer-clean" in debian/rules(clean), to avoid diffing > Makefile.in files, and > 2. insert the proper sequence of "aclocal -I m4", "autoheader", > "autoconf", etc in debian/rules(configure). The proper sequence: aclocal -I filename.m4, autoheader, automake, autoconf. You can define it, for example. as "preconfigure" in debian/rules because you have to use it just once. Probably you will not avoid to rebuild configure stuff but I think it's not a problem, just only bigger *.diff.gz. Mariusz -- Mariusz Przygodzki | Good judgement comes from experience. [EMAIL PROTECTED] | Experience comes from bad judgement. http://www.dune.home.pl | GPG KeyID: 0x42FAD771 GPG Fingerprint: 1990 F07B FFB4 BE0B FF26 10C2 BE2B 965C 42FA D771
