Re: changes in Makefile.am

[Dominique Devriese <dominique.devriese@student.kuleuven.ac.be>]

Zsolt Rizsanyi writes:

> Hi!  Are there any guidlines on how to package a kde application
> where changes are necessary in one or more Makefile.am-s ?

> If I just leave the Makefile regeneration to the make process then
> it does not succeed because the automake version of the upstream
> does not match the version I have from debian.

This is indeed the wrong idea.

> If I try to rebuild the makefiles I get problems with *.moc
> autogeneration.

I'm guessing that you only ran automake, and did not do "make -f
admin/Makefile.common".  See below.

> Is there some solution to these problems?

The best way to deal with this is ( credit for all the nice tricks
goes to calc ;) ):

1 download the source of the package, and put it in appname-version
2 tar it up to appname_version.orig.tar.gz
3 enter the directory, make changes to the debian/* directory if
  necessary.
4 Add a patch to your debian patches, that changes
  admin/configure.in.min by putting a call to "AM_MAINTAINER_MODE"
  after the AM_INIT_AUTOMAKE call.  This makes sure that the
  Makefile's are never rebuilt, even if the Makefile.am's change.
  It's now up to the maintainer ( i.e. you ) to make sure that the
  Makefile's are up to date.  We will take care of this in the next
  point.  Note that this adds an option "--enable-maintainer-mode" to
  configure.  Do *not* call this, or you will be back to the previous
  situation where makefile's are rebuilt when the Makefile.am changes.
5 Apply all the patches.
6 Run "make -f admin/Makefile.common" to create the configure script
  and all the Makefile.in's.
7 Unapply the patches
8 Build the package.

This procedure avoids unnecessary rebuilds of the Makefiles, allows
you to change whatever you want in the Makefile's, creates a very ugly
.diff.gz ( containing all the differences between the Makefiles
generated by upstream, and those generated by us ), but that's not a
problem if you properly made all your changes as patches ( which you
should always do anyway :) ).

There is an additional difficulty for packaging up KDE CVS modules,
namely that we have the habit of including the latest fixes from the
current BRANCH into the package.  For this, a diff between the
_RELEASE and _BRANCH tags needs to be generated and added to the
debian patches ( somewhere between point 3 and 4 above ).  This isn't
necessary for normal KDE applications though.

I hope this is a bit clear, if you have any more questions, please
ask. 

cheers
domi