On Mon, 14 Mar 2011, Vincent Torri wrote:
Thanks for your feedback to help us improve the configure script!
>> 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.
Sure, and I am the maintainer of several open source packages since 1997 and I
have.
I have learned that you just never stop getting these problems. It just
depends on what users you have and what particular esoteric platforms and
operating environments they have and use to torture your setup with. Thus, it
doesn't matter if you've done it for 7 years. The really odd cases just show
up once and get fixed and you may never see them again.
> And if it's just for libtool, then it's really not needed. Which problems
> did you have exactly ?
We did our own tests originally because the internal tests didn't properly
bail out when these tools weren't found, which then caused very odd errors
(much) later on in the build process when they were used.
>> 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.
Sure, when everything works and is dandy. But when users of platform Y figure
out that autoconf broke in some aspect for their platform in version Z, those
users can then still run autoconf version Z-1 on the source and be happy as
long as we keep the scripts good and proper for such older versions.
> 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.
If the configure script we ship isn't good enough for the users, I want to
either fix the current script to work or provide a decent work-around.
> You can say to all developpers to use a minimal version for the autotools,
Sure, some degree of "no earlier than version X" is reasonable, but the
version Xs in the world of autoconf and automake have to be rather old to
guarantee wide functionality. See for example how automake regularly have been
broken on Solaris or how autoconf is "suboptimal" on VMS since 2.61 etc.
> 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).
Ah, I get it now. Thanks, I'll fix!
>> 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)
I'll appreciate a proper diff so that I don't misunderstand!
> No, I'm saying that you should use the correct variable on Windows. You
> should use SSIZE_T.
Ok, so config-win32.h can do this and everything builds fine?
#define ssize_t SSIZE_T
> 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).
The way we do it in config-win32.h now already works on those platforms, it
just isn't done as nicely...
-- / daniel.haxx.seReceived on 2011-03-15