Landry Breuil <[email protected]> writes:

> On Fri, Apr 03, 2015 at 02:01:42PM +0100, Jérémie Courrèges-Anglas wrote:
>> Landry Breuil <[email protected]> writes:
>> 
>> > On Fri, Apr 03, 2015 at 01:17:30PM +0100, Jérémie Courrèges-Anglas wrote:
>> >> 
>> >> Hi,
>> >> 
>> >> knot is an alternative authoritative nameserver implementation.  A few
>> >> people seems interested in it.
>> >> 
>> >>   https://www.knot-dns.cz/
>> >> 
>> >> Here's a port, along with the required liburcu package
>> >> (http://urcu.so/).  I'm not sure about the portability of both packages,
>> >> so build reports on !(amd64|sparc64) would be welcome.
>> >> 
>> >> Used in a slave amd64 setup by Pierre Emeriaud, lightly tested by me
>> >> with the example.com.zone.
>> >
>> > Regarding liburcu, i'm not sure of the autohell handing .. isnt setting
>> > CONFIGURE_STYLE = automake autoconf doing what's needed instead of
>> > running autoreconf ? iirc this automagically sets BDEPs too while here.
>> 
>> "CONFIGURE_STYLE = automake autoconf" requires a do/pre-configure target
>> anyway, so I used to handle this with just autoreconf.  I could change
>> this of course but (IIRC) this idiom is already used in the tree.  Is it
>> harmful?
>
> Using automake autoconf in CONFIGURE_STYLE at least takes care of the
> BDEPs, see ports/infrastructure/mk/gnu.port.mk :) autoreconf itself is
> fine i think.

It's a bit more complicated...

> CONFIGURE_STYLE =     autoconf automake
> CONFIGURE_ARGS +=     ${CONFIGURE_SHARED}
> 
> AUTOCONF_VERSION =    2.69
> AUTOMAKE_VERSION =    1.11
> 
> pre-configure:
>       cd ${WRKSRC} && env ${MAKE_ENV} \
>           AUTOCONF_VERSION=${AUTOCONF_VERSION} \
>           AUTOMAKE_VERSION=${AUTOMAKE_VERSION} \
>           autoreconf -vif

->

joy /usr/ports/mystuff/devel/liburcu$ make clean all
===>  Cleaning for liburcu-0.8.6
===> liburcu-0.8.6 depends on: metaauto-* -> metaauto-1.0p1
===> liburcu-0.8.6 depends on: automake->=1.11,<1.12 -> automake-1.11.6p1
===> liburcu-0.8.6 depends on: autoconf-2.69 -> autoconf-2.69p1
===> liburcu-0.8.6 depends on: gmake-* -> gmake-4.1p0
===>  Verifying specs:  pthread
===>  found pthread.18.1
===>  Checking files for liburcu-0.8.6
`/home/distfiles/liburcu-0.8.6.tar.gz' is up to date.
>> (SHA256) liburcu-0.8.6.tar.gz: OK
===>  Extracting for liburcu-0.8.6
===>  Patching for liburcu-0.8.6
Running autoconf-2.69 in /usr/obj/pobj/liburcu-0.8.6/userspace-rcu-0.8.6
configure.ac:15: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:163: error: possibly undefined macro: AM_CONDITIONAL
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2678 
'/usr/obj/pobj/liburcu-0.8.6/.patch_done': @for d in /usr/obj/pobj/liburcu-0...)
*** Error 1 in /usr/ports/mystuff/devel/liburcu 
(/usr/ports/infrastructure/mk/bsd.port.mk:2473 'all')

Same with just "automake" in post-patch. Input welcome, but I think that
the proposed CONFIGURE_STYLE is fine as is.

>> > That said, it builds fine on i386, and on powerpc it's still chewing
>> > zscanner.c ...
>> 
>> We could use --disable-fastparser on slow/memory-limited archs.
>
> Took more minutes but eventually succeeded.

Cool.  The knot project only advertises support for x86/amd64, but if it
builds (and works) elsewhere, let's use it.  My main concern was with
liburcu actually, which seems to use arch-specific asm but also has
"generic", probably less tested atomics support.  Yet another
BROKEN-hppa candidate?

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply via email to