On 06-06-10 19:25, Magnus Holmgren, Millnet/Lysator/Debian/Mensa @ Pike developers forum wrote:
On 06-06-10 18:15, Magnus Holmgren, Millnet/Lysator/Debian/Mensa @ Pike developers forum wrote:
If the diff is manageable I prefer to patch configure and avoid depending on and running autoconf. I suppose that's the only reason for the last hunk of rules.diff.
I don't exactly understand what you mean here? If configure.in in pike is patched, then for every new stable release configure will also be correct thereafter?
It's just that it tends to produce huge diffs when building a package twice in a row unless all the files created by autoconf are restored or deleted by debian/rules clean.
If configure.in is patched in pike before autoconf is used to export the stable pike, autoconf doesn't have be run anymore from debian/rules and can be left out. Even for emdebian.
The patch to debian/rules is for the current package 7.8.352. But I think it is far less complex to try and make it right in the next stable release of pike. (So then the added line "$(MAKE) force_autoconfig CONFIGUREARGS="$(CFARGS)" can be left out.)
I'm not sure that packages are allowed to build-depend on themselves, but I suspect that the same bootstrapping problem may exist with other packages as well?
Since it is only a problem when cross-compiling I don't think it is right to make the package depend on itself for building. I'd opt for the build process failing and leaving it up to the cross-compiler to see that pike is missing on the host.
But to be sure I'll ask in the emdebian community.