Hello all,<br><br>I'm an XEmacs developer who decided that if I keep putting my pet projects [1]<br>off until I have more free time, that I'll eventually die from old age without<br>having started them. :-) I'm out CL shopping at the moment. I've spent the<br>
last few weeks trying out SBCL, and I'm ready to turn my attention to ECL now.<br><br>I had a little trouble getting ECL 11.1.1 to build with the options I wanted.<br>I'm going to post a series of small patches that fix things up for me. Is it<br>
better to send patches to the mailing list, post them on the Sourceforge patch<br>tracker, both?<br><br>Here's the rationale for the attached patch, hunk by hunk.<br><br>aclocal.m4 changes:<br>Hunks 1, 3, and 4: AC_TRY_COMPILE and AC_TRY_LINK are obsolete, and have been<br>
replaced elsewhere already.<br>Hunk 2: AC_LANG_PROGRAM already generates a main() function, so the current<br> code generates a main() inside a main().<br><br><a href="http://configure.in">configure.in</a> changes:<br>
Hunk 1: AC_ISC_POSIX is obsolete. The strerror check is its replacement.<br>Hunk 2: On my platform (Linux: Fedora 14), the ECL_POSIX_SEMAPHORES and<br> ECL_POSIX_RWLOCK checks look for functionality that is in libpthread<br>
... which isn't added to LIBS until AFTER the checks have been run,<br> resulting in spurious failures. This hunk just moves the addition of<br> THREAD_LIBS to LIBS and THREAD_CFLAGS to CFLAGS to before those tests.<br>
Hunk 3: There is no AC_MSG_RESULT paired with the deleted AC_MSG_CHECKING,<br> resulting in funny-looking output. Plus, it appears that the result<br> of this "check" is constant, which makes me believe that the message<br>
is superfluous.<br><br>And I'll apologize in advance for my response time. I'm doing this on my<br>personal time == (not (or at-work talking-to-wife reading-to-kids)). I'll<br>sometimes take a day or two or three to get around to things.<br>
<br>Regards,<br>-- <br>Jerry James<br><a href="http://www.jamezone.org/">http://www.jamezone.org/</a><br><br>Footnotes:<br>[1] The pet project I would REALLY like to undertake is to rip Emacs Lisp out<br> of XEmacs by its roots and insert a Common Lisp engine, such as ecl, in<br>
its place. But my estimate for the number of man-hours that would take<br> is, regrettably, much too high to be feasible. Sigh.<br><br>