Front page | perl.perl5.porters |
Postings from March 2018
On Tue, Mar 20, 2018 at 10:01:26PM +0200, Sawyer X wrote: > > > On 03/13/2018 08:05 PM, Karl Williamson wrote: > > There is some complicated code for Ultrix in locale.c that I've never > > been comfortable with. Now I find that the last release of this OS > > was in 1995, and the last post in comp.lang.ultrix was in 2013 (ilmari > > checked that) > > > > I added this comment some years ago > > > > /* XXX This is to preserve old behavior for Ultrix > > * when i==0, but I (khw) don't think that behavior makes much > > * sense */ > > > > > > I'd like to get rid of that, and from having to spend time on > > considering this special case when working with this file. > > > > I'm thinking we don't need to keep up support for this OS any longer. > > If the OS is outdated and unsupported, it is possible (dare some might > say, likely) it won't build on new versions of Perl for other reasons. A > different problem, raised previously by Jim, I think, is that we have no > way of verifying it still works - and any outdated OS we also do not > have access to makes it doubly difficult to maintain the code for. If > the code in question is in the way, it's good reason to remove it. > > Any objections? My (lovely) Ultrix box died a while ago, so I have nothing left on which to test this. In general, I would not advocate removing support for an OS just because we are unable to test it, but there is a difference if that means managing complicated code just for that OS. That seems to be the case here, so in this case I would also not be against dropping Ultrix support. As I recall, Ultrix did not support dynamic loading. Do will still support any OS with this limitation, or does dropping Ultrix mean that we can also drop support for only static builds? And if so, is that actually of any value or are we just always following the static build path in that case? Perhaps Configure can be simplified? -- Paul Johnson - paul@pjcj.net http://www.pjcj.netThread Previous | Thread Next