On Mar 2, 2010, at 05:23, Ludovic Courtès wrote:
>>> We don't actually reference yyget_leng elsewhere explicitly; can we just
>>> get rid of the declaration?
>>
>> This patch has been working fine for me on my Mac; we may be able to delete
>> more of the declarations, depending what other lex implementations do
>
> Keep in mind that ‘c-tokenize.c’ is part of the distribution, so we
> shouldn’t worry much about what Flex implementations do, as long as the
> file we ship compiles fine.
True for most people (if they don't do things that cause timestamps to randomly
get updated, like using a version control system or copy program that doesn't
preserve timestamps), though that just pushes the compatibility issue over to
whatever lex/flex version the person building the distribution has.... But, as
long as they try it out before putting it up for download, we should catch any
problems fairly easily.
> I don’t have any problem with Flex 2.5.35. Which version do you use?
Mac OS X includes flex 2.5.35, though I can't assert that Apple hasn't tweaked
it any. I tried this little test case:
> % cat q.lex
> %%
> "hello" { return HELLO; }
> %%
> % flex q.lex
> % grep yyget_leng lex.yy.c
> yy_size_t yyget_leng (void );
> yy_size_t yyget_leng (void)
> %
And yy_size_t is defined to be size_t.
Does it not insert such declarations for you on your system?
>> - "$(srcdir)/$(snarf_doc).scm" > "$...@.tmp"
>> + "$(snarf_doc).scm" > "$...@.tmp"
>
> This one seems wrong to me since $(snarf_doc).scm is in $(srcdir), not
> $(builddir).
Yes, though changing load-module to interpret paths relative to the working
directory rather than the currently loading module looks wrong too.
>
> Instead I suggest changing $(srcdir) to $(abs_srcdir), which should
> solve the problem.
Thus sidestepping the whole question of how a non-absolute pathname argument to
make-texinfo.scm should be interpreted.... Perhaps it should complain if you
give a non-absolute name, if we're not going to settle the question?
> Can you confirm and commit?
Sure -- done, and done. And with the right upstream branch name this time. :-)
But... a new issue -- with SCM_DEBUG=1, my build fails:
GUILE_AUTO_COMPILE=0 \
../meta/uninstalled-env \
guile-tools compile -Wunbound-variable -Warity-mismatch -o
"language/glil/decompile-assembly.go"
"../../module/language/glil/decompile-assembly.scm"
Non-pair accessed with SCM_C[AD]R: `#<unknown-type (0x13d . 0x101a239a0) @
0x101a23960>'
make[2]: *** [language/glil/decompile-assembly.go] Abort trap (core dumped)
(gdb) bt
#0 0x00007fff81777fe6 in kill ()
#1 0x00000001000cfb5f in scm_error_pair_access (non_pair=0x10195e230) at
../../libguile/pairs.c:64
#2 0x0000000100022275 in scm_i_dowinds (to=0x101e125e0, delta=1, turn_func=0,
data=0x0) at ../../libguile/dynwind.c:309
#3 0x0000000100022390 in scm_dowinds (to=<value temporarily unavailable, due
to optimizations>, delta=<value temporarily unavailable, due to optimizations>)
at ../../libguile/dynwind.c:228
#4 0x000000010001a79e in scm_c_abort (vm=0x1006f3040, tag=0x101a239a0, n=5,
argv=0x7fff5fbfd3a0, cookie=50450) at ../../libguile/control.c:230
#5 0x00000001001128ce in vm_abort (vm=<value temporarily unavailable, due to
optimizations>, n=<value temporarily unavailable, due to optimizations>,
vm_cookie=<value temporarily unavailable, due to optimizations>) at
../../libguile/vm.c:229
#6 0x000000010011a857 in vm_debug_engine (vm=0x1006f3040, program=0x101083520,
argv=0x101001970, nargs=1) at vm-i-system.c:1546
[....]
I note that 0x13d & 0x7f is 61 or scm_tc7_prompt...
Ken
