Re: Plan for 2.0

[Neil Jerram]

Hi Ludo!  Thanks for your responses...

2009/1/8 Ludovic Courtès <address@hidden>:
> Hi Neil,
>
> "Neil Jerram" <address@hidden> writes:
>
>> 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")).

That's good, but I think I didn't explain the possible problem fully,
i.e. that the substitute won't work.  Because of how Guile saves and
restores continuations (by copying the stack), and how it uses alloca
to create space for debug information on the stack, we must have an
alloca() that really does use the stack, and not one that uses the
heap.  And when I last checked, the common substitute definition of
alloca() uses the heap.

So, (i) am I still missing something, or (ii) does the substitute
definition use the stack now, or (iii) is there a way to tell Gnulib
that we really need an on-the-stack alloca (and that the build should
fail if there isn't one), or (iv) are we already doing (iii) and I
just missed it :-) ?

(We originally addressed this, somewhere in 1.6.x or 1.8.x, here:
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=31e4c69e95bc77b7f701348a32ffc8374ad8a0e5)

>> serial number in guile.m4
>
> Why is that?  Are there differences?

master has a line "serial 9", branch_release-1-8 doesn't.  I believe
it's a standard of some kind to have a "serial" line, so we added it
in master, but preferred to avoid perturbing 1.8.x.

>> 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'.

I would have thought that the point of eval.i.c is to hold the code
that gets compiled twice (debug and non-debug).  If there is #ifdef
DEVAL code in eval.i.c, it seems to be better to move it back to
eval.c.

>> 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.

I can't immediately remember what the latest consensus on that was...

>> 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.

Thanks for those.

>> ChangeLogs still in distribution?
>
> Yes, same as for `branch_release-1-8'.

OK, thanks.

>> 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, I'll look into that.

> Thanks,
> Ludo'.

Regards,
        Neil