[Ecls-list] Configuration patch

Jerry James loganjerry at gmail.com
Wed Jan 19 03:52:53 UTC 2011


Hello all,

I'm an XEmacs developer who decided that if I keep putting my pet projects
[1]
off until I have more free time, that I'll eventually die from old age
without
having started them. :-)  I'm out CL shopping at the moment.  I've spent the
last few weeks trying out SBCL, and I'm ready to turn my attention to ECL
now.

I had a little trouble getting ECL 11.1.1 to build with the options I
wanted.
I'm going to post a series of small patches that fix things up for me.  Is
it
better to send patches to the mailing list, post them on the Sourceforge
patch
tracker, both?

Here's the rationale for the attached patch, hunk by hunk.

aclocal.m4 changes:
Hunks 1, 3, and 4: AC_TRY_COMPILE and AC_TRY_LINK are obsolete, and have
been
        replaced elsewhere already.
Hunk 2: AC_LANG_PROGRAM already generates a main() function, so the current
        code generates a main() inside a main().

configure.in changes:
Hunk 1: AC_ISC_POSIX is obsolete.  The strerror check is its replacement.
Hunk 2: On my platform (Linux: Fedora 14), the ECL_POSIX_SEMAPHORES and
        ECL_POSIX_RWLOCK checks look for functionality that is in libpthread
        ... which isn't added to LIBS until AFTER the checks have been run,
        resulting in spurious failures.  This hunk just moves the addition
of
        THREAD_LIBS to LIBS and THREAD_CFLAGS to CFLAGS to before those
tests.
Hunk 3: There is no AC_MSG_RESULT paired with the deleted AC_MSG_CHECKING,
        resulting in funny-looking output.  Plus, it appears that the result
        of this "check" is constant, which makes me believe that the message
        is superfluous.

And I'll apologize in advance for my response time.  I'm doing this on my
personal time == (not (or at-work talking-to-wife reading-to-kids)).  I'll
sometimes take a day or two or three to get around to things.

Regards,
-- 
Jerry James
http://www.jamezone.org/

Footnotes:
[1] The pet project I would REALLY like to undertake is to rip Emacs Lisp
out
    of XEmacs by its roots and insert a Common Lisp engine, such as ecl, in
    its place.  But my estimate for the number of man-hours that would take
    is, regrettably, much too high to be feasible.  Sigh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110118/4a8d586b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecl-configure.patch
Type: application/octet-stream
Size: 3883 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110118/4a8d586b/attachment.obj>


More information about the ecl-devel mailing list