On Sat, Nov 01, 2003 at 08:06:36PM +1100, Ben Burton wrote: > > > This really shouldn't be done like this since it requires autotools for > > the build environment. > > koffice build-depends on automake/etc, so it shouldn't break anything. This only doesn't break anything as long as automake is forced to run on every build. Otherwise every minor revision upgrade of automake will break the build. > This actually doesn't change anything from koffice's behaviour over the > last couple of years - I simply added the patch now because I was > building from an upstream tarball instead of from a CVS checkout. As you mentioned below once we move to alioth we will probably want to make sure everything builds in a similiar fashion. We can wait to discuss it further until then. > Your method does look reasonable for packages that don't have patched > Makefile.ams. Though koffice does (have patched Makefile.ams), and part > of the reason for running automake at build time is the patches can all > stay in the one place (debian/patches). This requires automake to be > run at build time since the patches are applied at build time. I'm > presuming the reason the debian/patches system was first introduced was > to make it easier for other people to make builds from random CVS > checkouts, which suits me fine. The method I use is specifically for when original (ungenerated) build files have to be modified (ie configure.in, Makefile.am, etc). There are some other problems with using make cvs-clean that I will go into later if you want to know, which afaict is the only way to clean up after running automake at build time. > Anyway, koffice is uploading now and a whole lot of build structures are > about to change with the move to alioth, so since nothing is broken I'm > quite happy to leave this discussion till after the alioth thing settles > down and koffice has another upstream release. Ok. Chris
Attachment:
signature.asc
Description: Digital signature