> (I personally prefer to > do that in configure, and to remove config.{sub,guess,log,status} in > clean, so that diff files are cleaner,

I wish everybody did it that way. I'm also happy to see that it's now how dh-make will do it, good.


{{{> > No you should not change orig.tar.gz, it should be exactly the same as > > upstream provides (unless you have good reason to do so). Just delete > > them in clean under same condition you use for copying them > > from /usr/share, this way the change won't be present in diff. > > How about > > * build-depend on autotools-dev > * move the upstream config.guess and config.sub to > config.{guess,sub}.upstream in the configure target > * copy the guess/sub from the autotools-dev location into the > build tree, again in the configure target > * if the *upstream files exist; move them back over sub/guess in > the clean target > > That way you don't modify the orig tarball; you're guaranteed to have an > appropriate and up-to-date sub/guess; the unpacked source is back to > pristine upstream after the make clean target, which is particularly > nice if you have your tree in a VCS and don't want to keep filtering the > sub/guess changes out of commits.

Again: there is no need to save the old config.guess and config.sub. Just delete them in clean and copy them in before configuring, all problems solved.


> Again: there is no need to save the old config.guess and config.sub. > Just delete them in clean and copy them in before configuring, all > problems solved.

Because:

> the unpacked source is back to pristine upstream after the make clean > target, which is particularly nice if you have your tree in a VCS and > don't want to keep filtering the sub/guess changes out of commits.

That is, if you branch, make a change, do a build, see it worked, do a clean, then want to commit your change, you don't have config/sub diffs in your commit (or have to fix them by hand for each feature add). Also, if <state 0> -> build -> <state 1> -> clean -> <state 2> and state 0 != 2, there's the potential for "not the same two builds in a row", which afaik is a QA goal for lenny.

But I haven't seen anyone actually do this in packages, so I'd love to hear people's opinions on the matter.}}}


{{{> Wih my study, i read than Makefile.am is necessary > for rules ?

No. The .am means "_a_uto_m_ake template". Such files need to be processed with automake first. If you just want to write a simple Makefile, then call it "Makefile" (see `man make') and add the rules to create your binary to the file. The make-doc package will help you and tell you more about built-in rules. See especially section 2 for a sample Makefile.}}}