[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backward compatibility status
From: |
Patrick McCarty |
Subject: |
Re: Backward compatibility status |
Date: |
Fri, 2 Apr 2010 11:21:46 -0700 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
Hi Ludo,
Sorry about the delayed response...
On 2010-03-15, Ludovic Courtès wrote:
>
> Patrick McCarty <address@hidden> writes:
>
> > 2010/3/6 Ludovic Courtès <address@hidden>:
> >> | 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.)
Okay, thanks. I didn't make that connection at first. :-)
I think, eventually, LilyPond should migrate away from using these
"internal" functions, but that's not something I'm able to figure out
right now.
> > 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?
Is the attached patch for LilyPond what you had in mind?
I'll apply it if it looks okay to you. I've tested with both Guile
1.8 and 1.9, and it seems to work OK.
> > 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 will. Thanks, for your support.
Regards,
-Patrick
0001-Add-checks-for-new-types-in-Guile-2.0.patch
Description: Text document
- Re: Backward compatibility status,
Patrick McCarty <=