Front page | perl.perl5.porters |
Postings from May 2016
On Wed, May 18, 2016 at 4:21 AM, Dave Mitchell <davem@iabyn.com> wrote: > On Tue, May 17, 2016 at 06:30:56PM -0600, Karl Williamson wrote: >> > I've never been entirely clear what the *actual* point of mathoms.c is. >> > I had always assumed it was to allow binary compatibility: i.e. >> > when something is converted from a function to a macro, XS code that >> > had been compiled to use that function would still dynamically link >> > against a newer perl in the same series. >> >> I was just guessing, based on the comments I saw, and the fact that it >> doesn't get cleaned out. > > Unless anyone objects, I think we should > > 1) empty mathoms in blead now; > 2) if no problems occur, add it as a new post-major-release step in the > RMG. I have no objection, but I can perhaps explain what mathoms.c is/was for. As long as the old symbols are still around, there is the possibility of preserving binary compatibility across versions and thus not requiring folks to rebuild all their extensions every year. We didn't choose not to do that because it's bad, but because it's hard. There are a great many platform-specific headaches that would have to be worked through, it would take quite a bit of vigilance to keep it working, and there would be certain types of changes that would be disallowed in versions that are expected to be binary compatible with their predecessors (e.g., changing the number or type of function arguments). As long as the current release model with no binary compatibility from year to year is the only one folks think we'll ever have, then it's true that it doesn't make much sense to keep the old functions in mathoms.c indefinitely. But I think better binary compatibility was still a goal when mathoms.c came along.Thread Previous | Thread Next