|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Tue, 29 Jan 2008 03:37:08 -0500 (EST) From: Tim Abbott <tabbott@MIT.EDU> To: Greg Hudson <ghudson@mit.edu> cc: athena10@mit.edu In-Reply-To: <1201577581.5864.12.camel@error-messages.mit.edu> Message-ID: <Pine.LNX.4.64L.0801290324560.3999@coset.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Thanks for the detailed response. I think it's probably worth figuring out whether it can be simplified using DEB_AUTO_UPDATE_AUTOCONF and friends, but I'm convinced they won't do what you want. We can either have each package have files like install-sh, in them (like Debathena does) or keep them outside the package (as athena.mk does). This design question is supposed to be related to the same question as whether one should treat the package as Debian-native, or as something intended to be distributed independently. Along with the more minor version bump issue, this is why I think we should revisit the "debian-native" question and try to reach an agreement. -Tim Abbott On Mon, 28 Jan 2008, Greg Hudson wrote: > On Mon, 2008-01-28 at 21:24 -0500, Tim Abbott wrote: >> One simplication would be using the DEB_AUTO_UPDATE_AUTOCONF variable >> (which is supposed to be set to a version of autoconf like 2.50, but some >> Debathena packages erroneously set to 1); it handles adding the >> autotools-dev and autoconf dependencies, and actually running autoconf. > > It's designed for packages which include their own configure scripts. > Practically speaking, I think it would work, except that it wouldn't > remove configure in the clean target. > >> I think using DEB_AUTO_UPDATE_AUTOCONF would also allow us to remove the >> config.sub and config.guess copying, since that gets done by buildcore.mk >> already. > > buildcore.mk will only replace an existing config.sub and config.guess. > If they don't exist, it won't copy them in. (Creating zero-length files > in the rules won't work since makefile conditionals are evaluated prior > to execution of rules.) > >> I notice the Athena mkinstalldirs and install-sh seem to be the same as >> those provided by the automake1.10 package -- it might be preferable to >> use those than including our own copy. > > I was reluctant to add a dependency on a specific version of automake > for this purpose, since we aren't actually using automake proper. The > scripts do not change often (unlike config.guess or config.sub) so this > seemed less likely to require future maintenance. I'm flexible on this > point, though. In an ideal world these would be packaged with autoconf > rather than automake, but this isn't an ideal world. > >> Also, Anders observes that install-sh, libtool, and ltmain.sh seem to not >> be used in any of the Athena packages we're aware of; it may be that they >> can be eliminated entirely. > > install-sh is a hard prerequisite of all autoconf-generated configure > scripts. (Try removing install-sh and running configure.) libtool is > not used by an current Athena packages but it ought to be used by all > Athena libraries according to Debian policy as I understand it. > >> There are also DEB_AUTO_UPDATE_LIBTOOL, DEB_AUTO_UPDATE_ACLOCAL and >> DEB_AUTO_UPDATE_AUTOMAKE variables that could be used to get CDBS to >> perform some of these other steps. I think DEB_AUTO_UPDATE_ACLOCAL may be >> able to replace the code for creating aclocal.m4 (though we'd still need >> install /usr/share/debathena-build-common/aclocal.m4 somewhere where >> aclocal will look). > > I'll have another look at the libtool and aclocal logic. I don't recall > what I ran into which made ignoring it seem simpler. > > >
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |