nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Autoconf changes & new feature


From: Ken Hornstein
Subject: Re: [Nmh-workers] Autoconf changes & new feature
Date: Fri, 19 Nov 2010 18:56:03 -0500

>>While this isn't a big deal personally, I will hazard a guess that
>>this change is unacceptable to nearly every package distro.  I don't
>>know that we care, but I'd further guess that they'll either add the
>>functionality back in or (more likely) not include these versions of
>>nmh.
>
>Debian currently builds --with-cyrus-sasl=/usr/include
>which I think would correspond to just using --with-cyrus-sasl.
>And most distros ought to be able to cope with setting CPPFLAGS
>and LDFLAGS for the build.

Yeah, that's exactly what I was thinking (and really, why would setting
CPPFLAGS/LDFLAGS be unacceptable for packaging distros?  That's the way
nearly every other autoconf package works).  The problem we were running
into was that if your Cyrus-SASL shared library was in a non-standard
location, it only worked right for Solaris; everything else it broke.

>But I do think it would be nicer if changes to remove existing
>functionality and break back compatibility of build scripts
>were discussed first and committed second (this one will break
>my personal build-from-cvs setup, for instance, because I use
>the debian packaging on cvs sources). Also there doesn't seem
>to be anything in ChangeLog about this...

Sigh.  It was getting late, I had to go home ... I wanted to get
that stuff out there.  I'll do the ChangeLog later.

And I don't think it will break the debian packaging, because now
the argument to --with-cyrus-sasl is silently ignored.  So I think
it should still work fine.  If it doesn't, let me know and I'll gladly
fix it.  I could put a warning in there that arguments to --with-cyrus-sasl
are now ignored if that would be helpful.

>(I'd forgotten how lousy cvs was until I came back to
>nmh; I don't suppose we could get consensus on moving
>to a VCS with actual support for atomic commits and
>other modern conveniences? :-))

I kinda feel the same way.  My vote is for git, but the REAL
question is: where to put it?  

--Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]