[darcs-users] the problems with autoconf

[Karel Gardas]

Zooko,

first of all, like or dislike autotools the problem is we're probably
going to live with them till someone goes ahead and try various
autotools replacement for darcs on all the possible platforms. My guess
is that such attempt will spend more time than just fixing current
autotools issues on windows.

zooko wrote:
> Folks:
> 
> [...]
>
> Okay, the specific problems that I had with autotools yesterday were:
> 
> 1.  The current darcs autoconf scripts are not reliable at figuring  
> out, at configure time, what is going to be available at compile  
> time.  For example, ./configure will tell me that libcurl is  
> available, with various features, and then at compile time I will get  
> compile time errors saying that libcurl is not available.

Interesting. How such compile time errors look like?

> 2.  The underlying reason for this seems to be that autoconf is  
> designed with C in mind, and has lots of C-specific features  
> hardcoded in.  For example, I uninstalled the C compiler from my  
> system and re-ran configure, and it immediately exited with 
> 
> configure: error: C compiler cannot create executables
> 
> This shows that there is a problem in the configure script -- whether  
> the C compiler can create executables is irrelevant to the question  
> of whether the Haskell compiler will be able to create executables at  
> build time.

I'm not sure, but my view of this is completely different. As far as I
know ghc is using gcc for building final executable/library so gcc is
required for darcs compilation. Please correct me if I'm wrong! Thanks.

> Indeed, this is the source of the unreliability (issue  
> #1, above), the autoconf scripts sometimes conclude at configure time  
> that a certain feature is available because the C compiler can use  
> it, but then it turns out at build time that the Haskell compiler can't.

this just means that we need to be more strict in testing of features
available to ghc. Please see aclocal.m4 for various Haskell tests.

> 3.  It is really hard to debug or extend autoconf.  This is because  
> its design involves layers in which the higher layers emit code  
> (based on macro expansion) that gets interpreted by the lower  
> layers.  This is a neat idea because it re-uses existing tools (like  
> sh and GNU make), and it works fine when the code is free of bugs,  
> but when there is a bug (such as there always is when writing new  
> code) it is awfully hard to figure out where the problem lies.  I  
> spent all day yesterday trying to either (a) persuade it that the C  
> compiler is named "ghc",

I think this is wrong way.

> or (b) write specific macros like the ones  
> that droundy wrote [3] to test a Haskell compiler instead of testing  
> a C compiler.

and IMHO this is the right one.

> I didn't succeed at either one yet.
> 
> I really can't afford to spend another day on it, so for the moment  
> my work building a statically-linked darcs executable for Windows  
> which includes libcurl and SSL is stalled.

could you be so kind and post here what you have achieved so far? I
think the most important is your m4 macro for haskell/curl/ssl test.
Perhaps someone will spot the bug in your code or will be able to
continue where you have ended.

Thanks!
Karel
-- 
Karel Gardas                  kgardas at objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com