Hi Ludo,
On 14/03/10 23:38, Ludovic � wrote:
Hi Patrick,
Patrick McCarty<pnor...@gmail.com> writes:
2010/3/6 Ludovic Courtès<l...@gnu.org>:
[...]
| Name | Cause
|
|---------------------------------------+-------------------------------------------------|
| lilypond-2.13.9 | `scm_internal_hash_fold'&
`scm_t_hash_fold_fn' |
Is this something that should be fixed in LilyPond?
I think so, yes (especially since ‘scm_internal_hash_fold’ was intended
to be sort-of internal.)
For reference, I'm fairly certain this build failure was introduced
with Guile commit a07010bf1828704edd9a40cadb0eaf820b8f3638.
Yes, that’s the one.
If I add the typedefs to the appropriate LilyPond header file and use
them, the problem goes away, but I don't know if there are unexpected
side effects of this.
I think you want a fix that retains compatibility with 1.8. How about
having a ‘configure’ test checking for this typedef?
I am unable to test any further, because there are more build failures
down the pipeline. :-)
Heh. Let us know what other Guile-related failures you stumble upon!
I patched the Lilypond header files and code calling them to get round
the above problem, but then hit this one:
Code like this which dynamically declares procedures,and works fine in
V1.8.7 but barfs with V1.9.9
;;; This is OK
(define-public PLATFORM
(string->symbol
(string-downcase
(car (string-tokenize (utsname:sysname (uname)))))))
;;; This is OK
;;; This fails, but works in 1.8.7
(case PLATFORM
((windows)
(define native-getcwd
getcwd)
(define (slashify x)
(if (string-index x #\\)
x
(string-regexp-substitute
"//*" "/"
(string-regexp-substitute "\\\\" "/" x))))
(define-public (ly-getcwd)
(slashify (native-getcwd))))
(else
(define-public ly-getcwd
getcwd)))
