Re: questions about the autotools

On Sun, 13 Mar 2011, Vincent Torri wrote:

> 1) Where are grep, grep -E and ar used in the autotools ? It is said that it
> is needed by libtool, but libtool is perfectly capable of checking the
> availability of the tools. Actually, these tests are useless and are just
> making configure slower.

AFAIR, they were introduced a good while ago because of deficiances in the
original built-in tests. The experiences may come from the curl project as
lots of the configure stuff in c-ares is inherited from there.

> 2) Instead of your sed check, what about using AC_PROG_SED ?

... which also failed to work properly back in the days.

I'd be reluctant to remove anything of that unless you can prove with a
certain degree of certainty that I'm wrong or that the problems were before
autoconf 2.61 or something.

Unfortunately, autoconf is one of those projects were things often break when
we upgrade so we need to be able to (allow users to) run old versions to make
things work.

> 3) The current use of AM_INIT_AUTOMAKE is deprecated. See:
>
> http://www.gnu.org/software/automake/manual/automake.html#Public-Macros

I didn't read that (yet), how is it supposed to be done and since which
versions of automake and autoconf is this rule introduced?

> In addition, you don't need the version in ares_ver.h as it is already
> defined by AC_INIT

We may not _need_ it for some platforms but we generate both at the same time
so there's no risk for discrepancies there. We do need it in ares_ver.h to
properly support the platforms that can't run configure.

> 4) There is a check to build static libraries with PIC on AMD64-Linux &
> FreeBSD. what about calling AC_ENABLE_STATIC for those platforms ?

I don't know. The current fix seems to work and I've had no reason to consider
a different solution. Why would we change to AC_ENABLE_STATIC ?

> 5) For Windows desktop, if winsock2 header is available, you do
>
> if test "$ac_cv_header_winsock2_h" = "yes"; then
> winsock_LIB="-lws2_32"
> fi
>
> you don't check here the Windows CE platform. In that case the library is
> libws2.a, i.e. you have to set winsock_LIB to -lws2

So how do you suggest the test is made? Very few people use configure on
windows, and I've not yet experienced a single person who've used it for
Windows CE. If you're one, you're very welcome to help us in this area.

> 6) ssize_t is defined on Windows and it is named SSIZE_T :
> http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx Better using
> that instead of the check in config-win32.h, that is, if

Are you suggesting our test in config-win32.h isn't working?

> AC_CHECK_TYPE(ssize_t, ,
> AC_DEFINE(ssize_t, int, [the signed version of size_t]))
>
> fails, then check for SSIZE_T.

Most windows people won't use configure at all, so we can't limit things to
configure detections there.

Also, config-win32.h should probably not be used at all if you use configure
on windows.

> 7) You use LIBS to defined the value of the Libs.private entry of
> libcares.pc. It is a bad idea as LIBS is an environment variable that can be
> used by the user to define additional linker -l flags. Why not using
> directly CARES_PRIVATE_LIBS ?

I don't understand. libcares.pc.in already has this line:

    Libs.private: @CARES_PRIVATE_LIBS@

Isn't that "using directly CARES_PRIVATE_LIBS" ?

-- 
  / daniel.haxx.se