On Mon, Mar 14, 2011 at 9:59 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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.
>
I am the maintainer of the autotools of a dozen of libraries since 2004 and
I have never had such problems with sed and grep. And if it's just for
libtool, then it's really not needed. Which problems did you have exactly ?
>
> 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.
When you say 'users', I disagree. The autotools are for developpers, not
users. What users have is a tarball with a beautiful configure script (a
shell one). So users do not have to deal with autotools. If they have to,
they are on their own, it's up to them to a minimal knowledge about
autotools.
You can say to all developpers to use a minimal version for the autotools,
btw.
>
>
> 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?
the new version of the macro has been introduced since automake 1.6
(released in march 2002)
what is strange is that you already use the new AC_INIT version (which has
been introduced in autoconf 2.52, released in july 2001) See the NEWS file
of automake.
>
>
> 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.
i was not precise enough : you already pass the version to AC_INIT. It's
then useless to pass it to AM_INIT_AUTOMAKE., hence it's useless to get it
from ares_ver.h (you did so because you use the deprecated version of
AM_INIT_AUTOMAKE while not using the deprecated version of AC_INIT).
>
>
> 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 ?
well, i wanted to add that call. But ok, let's not change things that work.
>
>
> 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.
I am a person who supports Windows CE platform for some libs :) About how to
do the test, well, you did one just a few lines above in configure.ac (see
mingw32ce in the $host_os case)
>
>
> 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?
>
No, I'm saying that you should use the correct variable on Windows. You
should use SSIZE_T.
>
>
> 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.
ha, that's another story. In that case, use directly SSIZE_T. It will be
correctly defined whatever versin of Windows you use (Windows CE, Windows
desktop, 32 or 64 bits).
>
>
> 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" ?
>
No. You have forgotten the definition of CARES_PRIVATE_LIBS in configure.ac:
CARES_PRIVATE_LIBS="$LIBS"
line 869 of the current release tarball.
regards
Vincent Torri
Received on 2011-03-14