Re: NaCl support for Emacs (was: GnuTLS for W32)

[Carsten Mattner <carstenmattner@googlemail.com>]

On Tue, Jan 10, 2012 at 11:01 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Mon, 09 Jan 2012 09:26:21 -0500
>>
>> I'm interested in bringing in support for the NaCl cryptographic library
>> for Emacs, after 24.1 is out.  There is info on NaCl here:
>>
>> http://nacl.cr.yp.to/index.html
>
> Call me weird or old-fashioned, but that library's build procedure
> looks odd, to say the least.
>
> It's as if Make and Autoconf never existed: the entire build is done
> by a series of shell scripts, all of them called `do', which have
> specific knowledge about several platforms hardcoded into them (do the
> developers really intend to maintain all this mess?).
>
> On top of that, the top-level `do' modifies PATH and LD_LIBRAY_PATH
> (what?  why??) as it sees fit, and redirects all its output to a log
> file, so you basically run blind, like in bad old DOS days (can you
> say "tail -f"?).
>
> Also, the scripts run all kinds of non-standard tools and compiler
> switches, and although they seem to ignore the resulting errors, how
> would J.R. Hacker become confident that the build succeeded and she
> can use the results?  E.g., what do you get out of this snippet of the
> build log:
>
>  === Tue Jan 10 03:28:17 EST 2012 === checking gcc -m32 -fomit-frame-pointer
>  /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/libgcc.a when searching for -lgcc
>  /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/libgcc.a when searching for -lgcc
>  /usr/bin/ld: cannot find -lgcc
>  collect2: ld returned 1 exit status
>
> Is it good? is it bad? can I trust the results?
>
> Finally, there's no Makefile anywhere in sight, and no installation
> script that I could find.  Bye-bye, "make install-strip", hello manual
> installation.
>
> Sorry, but I wouldn't touch such "software" with a 3-mile stick.  Not
> for Emacs, anyway.

For better or worse Dan's software is packaged and licensed as he
sees fit. It is somtimes unconventional, but is something which can be
handled to get at the good stuff within :). People tolerate JavaScript to
get stuff done. We tolerate C as a (limited overhead) porting layer
between us and the machine.

Some reading material:
http://cr.yp.to/redo.html
https://github.com/apenwarr/redo
http://thedjbway.b0llix.net/future.html