Ian> CVS; oh well, I guess I have to do that anyway to contribute the
Ian> DNS packet code, but I'll have to convince the superiors it's safe.
Ian> Or should I wait for the next release?
Daniel> That's your pick. I plan to make a release "soon", but I'm not
Daniel> sure exactly when that is. There's no real rush to release as I
Daniel> see it.
I got the curl CVS tree, but unfortunately I am caught in the autotools
snare :-( Having to install multiple versions of each auto*, one for
each project, is bad enough; but I am also on FreeBSD, meaning my m4
is not GNU m4, and I am afraid to replace it.
<rant>
This is why I decided lately to avoid _any_ of the auto* (even autoconf,
which is the most useful of them) and program to strict SUSv3/POSIX.
I mean, how long are we going to support broken legacy platforms,
anyway?
</rant>
A secondary problem is that buildconf inside the ares subtree fails like this:
izimmerman@ianbuild:~/work/bsn/scs/contrib/curl/ares$ ./buildconf
configure.ac:23: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:41: error: possibly undefined macro: AC_DISABLE_SHARED
configure.ac:60: error: possibly undefined macro: AC_PROG_LIBTOOL
Makefile.am:3: Libtool library used but `LIBTOOL' is undefined
Makefile.am:3:
Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
Makefile.am:3: to `configure.ac' and run `aclocal' and `autoconf' again.
This might be because of the different m4, or because nobody ever tried
to build the subtree separately.
Ian
Received on Mon Jan 9 22:03:53 2006