Re: merge cleanup

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Mon, 23 Nov 2009 16:28:42 +1100

On Monday 23 November 2009 15:41:43 you wrote:
> On Sun, 22 Nov 2009, Murray S. Kucherawy wrote:
> >> remaining bug LIBOPENDKIM_FEATURE_STRING is constant of all features
> >> (enabled or not)
> >
> > For me it's "libopendkim 1.2.0:" if nothing is enabled, and then things
> > seem to be added as I enable them. What's the intent if not that?
>
> Actually it looks like only LIB_FEATUREs are added.
that was the intent even though LIBOPENDKIM_FEATURE_STRING is in build-
config.h and not available outside this build.

> There is one FFR
> ("dkim_reputation") that affects both opendkim and libopendkim.
add it as a libfeature for now. The only difference at the moment is
libfeatures get added to this string.

> We need
> to make sure that one gets covered as well. It and "diffheaders" are the
> only ones that affect both the library and the filter.
>
> There's one other issue I just spotted: the build-aux directory doesn't
> exist in CVS. So if you do a fresh trunk checkout, autotools will all
> fail because they can't create the missing components they want. If it
> needs to exist, you should probably make it
add it to the cvs repo sounds good. The make distcheck tarball has it all nice
and there.

> and just put a README in there
> explaining why it's needed.
probably overkill.

> Or, we might want to ressurect "autogen.sh"
> and have it do "mkdir build-aux" before doing aclocal, autoconf, automake
> and autoheaders, and then use that when preparing distributions.
the autogen.sh and its general flimsyness was the driver for autoconf to add
autoreconf in 2.50. As we are requiring 2.6* in configure.ac it should be
there.

> Apart from this and your tre-0.7.5 request (which I'm working on in
> VM-land now),
thanks. sorry to dump you with quick features and bits of mess while trying to
get a beta out.

looking good.

could use a AC_DEFINE(TRE_PRE_080) rather than pushing it into CFLAGS but
otherwise looks good. Would need perhaps more includes in other headers.

> I think this is looking much better now.

i agree.
Received on Mon Nov 23 2009 - 05:30:01 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:32:29 PST