On Wed, 2011-03-16 at 16:36 +0000, Ian Jackson wrote: > > Then, you need a way to patch them. There is lots of software where > > you need to patch configure.ac and/or Makefile.am > > That's fine, you patch the input, rerun the autofoobar stuff, and then > build the source package with diff. If you're using a patch queue > system, or a vcs, you arrange for the autogenerated autofoobar output > changes to be committed along with the corresponding input change. and then you end up with either (a) masses of changes to upstream files in your local branch which will cause merge conflicts (and aesthetically, ew, yuck.) or (b) a patch in your patch queue which will very likely not apply in the next upstream release. > > If you do it with the patch system (quilt or even plain dpkg), > > before building the package source, you cannot ensure that files are > > patched in the right order. > > What do you mean "in the right order" ? autofoo stuff examines timestamps on various files, so it's possible that if configure gets patched before configure.ac, and AM_MAINTAINER_MODE is set to a specific value, that ./configure ends up wanting to regenerate ./configure at build time. double fail. > > So Makefile rules can then re-run auto* tools at build time and you > > lost the benefit you want to have. > > Makefile rules should not rerun auto* stuff at build time. they will if AM_MAINTAINER_MODE is being used, in some cases. sean
Attachment:
signature.asc
Description: This is a digitally signed message part