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