develooper Front page | perl.perl5.porters | Postings from July 2018

Re: What platforms should we remove support from?

Thread Previous | Thread Next
From:
Philip Prindeville
Date:
July 31, 2018 03:53
Subject:
Re: What platforms should we remove support from?
Message ID:
135C55A9-2A48-4D28-94A1-6DC7CC08F312@redfish-solutions.com


> On Jul 29, 2018, at 12:15 PM, Karl Williamson <public@khwilliamson.com> wrote:
> 
> On 07/28/2018 06:16 PM, Tomasz Konojacki wrote:
>> On Sat, 28 Jul 2018 17:43:25 -0600
>> Karl Williamson <public@khwilliamson.com> wrote:
>>> We agreed to remove support for Ultrix in the thread beginning at
>>> http://nntp.perl.org/group/perl.perl5.porters/249983
>>> 
>>> What other ancient platforms should go (like Atari) ?
>> Recently there was some discussion about removing Windows CE support:
>> https://www.nntp.perl.org/group/perl.perl5.porters/2018/07/msg251510.html
>> Also, it's not really a platform, but dropping Visual C++ 6 support is a
>> recurring topic on this list, most recently in this ticket:
>> https://rt.perl.org/Public/Bug/Display.html?id=132766
> 
> ok.  Comments welcome on these.
> 
> I am of the opinion that we shouldn't remove stuff just because it's old and even disused.  As others said in the thread, only if it's causing us problems now should it be removed.  These problems could mean a bunch of specialized code for it, such as VC++6 has, or a bunch of open tickets that would require adding specialized code to fix.
> 
> So, for example, if the only specialized code is a hints file that just sets some compile options, I see no need to remove that hints file. However, if those options are essentially a euphemism for doing specialized code that applies just to the given OS, then it would be a candidate for removal.  Such is the case for Ultrix, which sets LOCALE_ENVIRON_REQUIRED.  That enables some complex code to be compiled, that is unused anywhere by in Ultrix.  And this is why I want to get rid of Ultrix.
> 
> I grepped through the hints files looking for other instances like this.  I found just these:
> 
> irix_5.sh:pp_sys_cflags='ccflags="$ccflags -DPERL_IRIX5_SELECT_TIMEVAL_VOID_CAST"'
> isc_2.sh:ccflags="$ccflags -DPERL_ISC"
> isc.sh:ccflags="$ccflags -DPERL_ISC"
> os2.sh:aout_ccflags="-DDOSISH -DPERL_IS_AOUT -DOS2=2 -DEMBED -I. $_defemxcrtrev -D__ST_MT_ERRNO__"
> os2.sh:aout_cppflags="-DDOSISH -DPERL_IS_AOUT -DOS2=2 -DEMBED -I. $_defemxcrtrev -D__ST_MT_ERRNO__"
> sco.sh:ccflags="-U M_XENIX -D PERL_SCO"
> 
> I did not look to see what these specialized options do, but I think these are a starting point of things to consider removing support for.
> 
> Even though the core C language files may not have much in the way of specialized support, the supporting modules shipped with core do.  There are a bunch of instances where $^O is examined.  I grepped for those, and threw out any .t or .pod files.  In the interest of moving forward, I compiled this list of platforms that are tested for, minus the ones I am confident that we want to continue to support:
> 
> amigaos
> android
> apollo
> bitrig
> dec_osf
> dgux
> dragonfly
> epoc
> haiku
> interix
> irix
> MacOS
> mint
> mpeix
> msys
> NetWare
> nto
> os2
> qnx
> riscos
> sunos
> symbian
> unicos
> unicosmk
> uts
> uwin
> vos
> 
> Don't be appalled if something you care about is on this list.  Just let the list know.  And even if something is on the list, if we decide it's not worth supporting, then we (or maybe just I) can look and see how much code is needed to support it, and if it's a trivial amount, I don't see a need to remove it.


“MacOS”?  Is there another name that OSX now uses?

Also, QNX still seems to be pretty active, as does Android.

The rest I’ve never heard of or haven’t heard of since the beginning of this millennium (NetWare, IRIX, Unicos, UTS, OS/2, DGUX, Apollo, etc).

-Philip

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About