Re: RFS: freemat
* Giuseppe Iuculano <giuseppe@iuculano.it> [080703 02:50]:
> > * After this unpatch no longer works. I think this is because you patch
> > Makfile.in files. As you call autoreconf, this can only be harmfull.
> >
> > * running autoreconf changes many files, many are not reverted by your
> > clean.
>
> I don't know how fix this, I need patching Makefile.in to fix UMFPACK search and so I need
> to call aclocal/automake/autoconf... How can I fix this?
There are multiple ways, with different requirements and up and downs:
1) Modifying Makefile.in
As Makefile.in in generated from Makefile.am by automake, if you modify
Makefile.in, you do not need to run automake (as
Makefile.am->Makefile.in is automake and Makefile.in->Makefile is configure).
a) Modify Makefile.am and Makefile.in
Also modifying Makefile.am has the advantage that upstream can make
better use of your patch and if someone takes the patched Debian
package, he can change Makefile.am and run automake and not loose the
changes you did.
The disadvantage of this is that unless upstream uses AM_MAINTAINER_MODE
in it's automake, there is always the danger of make running automake
and thus redoing Makefile.in again. (unless you make sure the timestamps
are correctly, i.e. in debian/rules touch Makefile.am, wait 3 seconds
(as some filesystems have 2 second resolution) and then touch
Makefile.in and hope that nothing evil happens).
b) only modifying Makefile.in
This makes it much more unlikely automake is run by make, but has the
danger that if it is done (for example a user copying the source dir,
thus destroying timestamps) may run automake (unless upstream uses
AM_MAINTAINER_MODE) and destroy your changes...
2) only modify Makefile.am and run automake (explicitly or implicitly)
Advantages: you modify the file upstream would modify (i.e. the real
source and not some intermediate file) and your patch is as minimal
as possible.
Disadvantages: You need to build-depend on automake, you need to hope
automake does not change in ways breaking your setup (was usual in the
past, the last years this has not happened, making this solution usually
the prefered one).
And you need to clean up afterwards, removing the generated files in
your clean target. (configure if you call autoconf (directly or via
autoreconf), config.h.in if you call autoheader (directly or
indirectly), all Makefile.in when you call automake, autom4te.cache if
nothing else removes that annoyance and so forth....
The easiest way to make sure you have removed anything generated, is
unpacking the source package, building it, then creating the source
package and looking at the diff. As you use debian/patches for all your
changes, the diff (best look at it with diffstat) should only contain
files in the debian dir.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
Reply to: