On Tue, 15 Mar 2011 22:29:57 +0000 Marcin Owsiany <porridge@debian.org> wrote: > The current best practice for dealing with packages using GNU > autotools (as described > in /usr/share/doc/autotools-dev/README.Debian.gz) is to run > autoreconf in a prerequisite of a build target, and to remove its > results in the clean target. > > However that README does not give any hints on how to best do the > cleaning. How are others doing it? Not every generated file needs to be cleaned. The list can vary if the package is very old and depends on how the package itself handles the clean internally. I'm upstream for a few packages which work this way, so I ensure that make distclean works correctly before every release, I use CDBS for the Debian build system working from the make dist tarball, build with svn-buildpackage, I use svn:ignore properties for some other files and then the problem just goes away. > I could think of the following ways: > > * maintain a blacklist of generated files, and "rm" them in the > clean target. A selective list is fine. > Looking (for example) at the amazing list of files that autopoint > copies into the po/ subdirectory, I have very little faith that > something new won't appear in the future. Not all those files matter. Besides, I've just done autoreconf on one of my upstream packages with lots of translations and autopoint didn't add any files - it's all just .po, .gmo, POTFILES* and Make*. > Since I use (or plan to use) git-buildpackage, I don't have a > tarball which could serve as an authoritative whitelist. Thus an > additional whitelist refresh step would be required every time I > merge the upstream branch into the debian branch. That's bad. Is this a case of a problem with a tool causing more work? Fix the tool? Change your choice of tool? Other tools, like svn-buildpackage, don't have this problem, via the mergeWithUpstream support and/or a ../tarballs/ directory. Not perfect but it works. cvs-buildpackage has a different problem (only with native packages using autotools) which bites me once in a while but not often enough to make me actually migrate the package concerned to svn. So I guess it's a matter of how much of an itch you can withstand. Using autotools with Debian native packages can be a real PITA and source format 3.0 just gets it wrong mostly. Most other tools also get it wrong, even svn-buildpackage. If I knew how to fix it reliably - *without* putting huge amounts of stuff into the VCS or massively extending the build by not using make dist (and missing errors by not using make distcheck), I'd stop using my own hand-crafted scripts to release these projects. Makes me wish I could pretend that these really are upstream packages. I think CMake makes a better job of native packages which need autotools-type hand-holding, so I may port to that instead. In other words - fix the tool(s), work with upstream and don't try to make life difficult for yourself (or people like me who really don't need this kind of thing to become Policy). Building direct from VCS is a nice idea but sometimes, it just isn't worth the pain - let the build system build the tarball and package from the tarball. It's just easier. Or just change the build system and/or the tool. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpxl13YRVyag.pgp
Description: PGP signature