Hello!
On 26-Jan-2001 Colin Watson wrote:
> Florian Hinzmann <[EMAIL PROTECTED]> wrote:
>>On 25-Jan-2001 Colin Watson wrote:
> If you can avoid changing configure.in and Makefile.in (actually, I hope
> that's Makefile.am?), then please do. Otherwise you can end up with huge
> diffs to the generated configure and Makefile.
No, I can't. But I don't have very large diffs. Neither
configure nor Makefile is distributed upstream, but both
are created from debian/rules. So there won't be diffs for
that files at all.
And it is Makefile.in, Makefile.am is not there.
Maybe that isn't as clean as it should be, but that won't
change too much. We're talking about XFMail, whose upstream
programmer discontinued his project. Now a group has picked up
the development and is porting XFMail to Archimedes which uses
GTK+ instead of XForms. Therefore support for XFMail is just a
step in the direction of Archimedes. IMHO they won't put very
much work into XFMail if it does not have some effect on Archimedes,
too. Once Archimedes is usable, XFMail won't be developed any further
at all. Therefore this has to run like it is and will disappear
someday.
> (As far as I know, incidentally, the build daemons typically don't use
> DEB_BUILD_OPTIONS. It's mainly intended for the convenience of users.)
I don't think so. One of the goals of this procedure is not
to waste CPU time while autobuilding binaries with -g and
striping them afterwards.
bye
Florian
--
Florian Hinzmann private: [EMAIL PROTECTED]
Debian: [EMAIL PROTECTED]
PGP-Key fingerprint: DD 61 74 34 04 FB 8A BD 43 54 83 38 0C 82 EF B1
