From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: Plan for 2.0
Date: Thu, 08 Jan 2009 22:43:21 +0100 [thread overview]
Message-ID: <878wpl79ty.fsf@gnu.org> (raw)
In-Reply-To: 49dd78620901071516j4592684du81efaf04cd95742a@mail.gmail.com
Hi Neil,
"Neil Jerram" <neiljerram@googlemail.com> writes:
> Below is a raw summary of all diffs between current branch_release-1-8
> and master. Next step is to check that everything here is correct,
> and properly+fully documented in the manual and in NEWS. The
> "Queries" at the end are bits that I'm not sure I understand yet.
Thanks for going through this.
> Use of Gnulib
> - linker warning
> - alloca - Have we inadvertently removed requirement for a real alloca?
No. Gnulib's `alloca' provides a substitute when that's needed and most
importantly provides the right #ifdefs to get a working `alloca ()' (see
`lib/alloca.in.h' and (info "(autoconf) Particular Functions")).
> serial number in guile.m4
Why is that? Are there differences?
> eval.c/eval.i.c
> - still need to compare old eval.c against new eval.i.c
> - why does eval.i.c contain code that is common to both modes and that
> is not compiled twice?
Like what? The top of the file is in `#ifdef DEVAL'.
> SCM_INTERNAL (grep diffs for SCM_INTERNAL to get list of affected functions)
Speaking of which, some functions were left external (e.g.,
`scm_i_string_chars ()') under the assumption that if we changed that in
1.8 (which was my plan back then) it would break apps. We may need to
revise that.
> Queries
> =======
> AC_SUBST(GCC_FLAGS)
This is so that we don't compile Gnulib code with `-Wall -Werror' since
Gnulib doesn't guarantee that this would work.
> lib-version.texi
This is for use in `api-i18n.texi', for instance.
> ChangeLogs still in distribution?
Yes, same as for `branch_release-1-8'.
> libguile in subdirs list of pre-inst-guile.in
Dunno why. The Right Way would be to use `libtool --mode=execute
-dlopen foo-bar.la' anyway.
Thanks,
Ludo'.
next prev parent reply other threads:[~2009-01-08 21:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-03 18:38 Plan for 2.0 Neil Jerram
2009-01-04 15:35 ` David Séverin
2009-01-04 16:25 ` Neil Jerram
2009-01-05 13:47 ` Neil Jerram
2009-01-05 15:21 ` David Séverin
2009-01-07 23:18 ` Neil Jerram
2009-01-04 16:27 ` Andy Wingo
2009-01-05 0:50 ` Greg Troxel
2009-01-05 17:21 ` Ludovic Courtès
2009-01-07 23:22 ` Neil Jerram
2009-01-08 13:48 ` Ludovic Courtès
2009-01-16 0:25 ` Neil Jerram
2009-01-17 23:05 ` BDW-GC-Guile incompatibilities Ludovic Courtès
2009-01-30 22:31 ` Neil Jerram
2009-02-18 22:50 ` Ludovic Courtès
2009-01-17 23:08 ` Plan for 2.0 Ludovic Courtès
2009-01-07 23:16 ` Neil Jerram
2009-01-08 21:43 ` Ludovic Courtès [this message]
2009-01-09 13:53 ` Neil Jerram
2009-01-12 17:08 ` Ludovic Courtès
2009-01-12 21:14 ` Neil Jerram
2009-01-12 22:12 ` Neil Jerram
2009-01-09 14:22 ` David Séverin
2009-01-12 11:10 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878wpl79ty.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).