Re: Deprecating OS support
Am Sat, 01 Oct 2022 21:52:03 +0300 schrieb Eli Zaretskii : > > From: Paul Smith > > Cc: bug-make@gnu.org, Juan Manuel Guerrero > > Date: Sat, 01 Oct 2022 14:48:01 -0400 > > > > On Sat, 2022-10-01 at 20:42 +0300, Eli Zaretskii wrote: > > > The DJGPP project has been routinely porting all versions of Make > > > up to and including 4.3. > > > > By "DJGPP project" I expect you are referring to the MSDOS port (I'm > > not familiar with all the alternative names). > > Yes. DJGPP is the MSDOS port of GNU development tools, based on GCC > and GNU Binutils. > > > The thing that I'm specifically looking at in the code are ifdef's > > using __MSDOS__. Are these the ifdefs used by DJPP? > > Yes. Sorry, I was abscent a couple of days so I could not respond to this. As Eli already pointed out __MSDOS__ is used by the DJGPP port. If this is an incoveniece may be a different macro can be used, like __DJGPP__ or what ever may see to you as appropriate. As long as the existing MSDOS/DJGPP support is still part of the make code I will continue providing ports for the DJGPP community. If I encounter some DJGPP specific issue I will try to provide a port to fix it. Regards, Juan M. Guerrero
Re: Deprecating OS support
On Sat, 2022-10-01 at 15:26 -0400, rsbec...@nexbridge.com wrote: > > I'm not familiar with the project names so can you be clear about > > which port(s) are used by HPE NonStop? Do both of these efforts > > refer to the VMS port? > > The NonStop ports would use __TANDEM not VMS. Hm. I don't see any code anywhere in GNU make that uses that preprocessor statement. > > However, I realize schedules don't always align so if it doesn't > > work that's OK. > > Timing is a big part of it yes. We cannot use the configure process > used by GNU Make for various resources, so must manually merge > changes into our code base and manually modify config.h and Makefiles > - at least for the Guardian ports. I used to maintain the OSS port > but that moved over to a different group some years ago. Making it > all work is a real pain and takes loads of time. We prefer to deal > with the official release and make it work afterwards. Our changes > likely not of general interest (handling weird non-POSIX file names, > strange system variables, process launch differences) so we have not > submitted them but they are available at GitHub if anyone wants to > look. Oh I see; you're maintaining this port outside the main source tree. That's fine but then it doesn't really fall into my purview and I won't say anything about it when I describe which OSs would be deprecated. Cheers!
RE: Deprecating OS support
On October 1, 2022 3:01 PM, Paul Smith wrote: >On Sat, 2022-10-01 at 14:02 -0400, rsbec...@nexbridge.com wrote: >> The ITUGLIB project team maintains a port of GNU Make for currently >> supported HPE NonStop Guardian platforms. We do intend to port 4.4 >> when it is released. I am the official maintainer on the team, at >> present. The HPE NonStop OSS (POSIX-compatible) platform port is >> maintained by HPE Development as part of their "coreutils" project. >> The latter's port tends to lag behind our port. > >I'm not familiar with the project names so can you be clear about which >port(s) are used by HPE NonStop? Do both of these efforts refer to the VMS >port? The NonStop ports would use __TANDEM not VMS. >In specific, I'm looking at the "VMS" preprocessor variable and all the code >ifdef'd >using that, plus the extra source files such as vmsify.c, vmsjobs.c, etc. Is >this what >is used by the ITUGLIB project? > >Does the NonStop OSS port use these as well, or does it configure itself as a >standard POSIX-style application and not use the VMS- specific code? > >> We do intend to port 4.4 when it is released. > >A release candidate for 4.4 was made a week or so ago and a second one will be >made most likely this weekend. It would be great if someone could try those, >that >way we could resolve any issues found before the release, rather than after. > >However, I realize schedules don't always align so if it doesn't work that's >OK. Timing is a big part of it yes. We cannot use the configure process used by GNU Make for various resources, so must manually merge changes into our code base and manually modify config.h and Makefiles - at least for the Guardian ports. I used to maintain the OSS port but that moved over to a different group some years ago. Making it all work is a real pain and takes loads of time. We prefer to deal with the official release and make it work afterwards. Our changes likely not of general interest (handling weird non-POSIX file names, strange system variables, process launch differences) so we have not submitted them but they are available at GitHub if anyone wants to look.
Re: Deprecating OS support
On Sat, 2022-10-01 at 14:02 -0400, rsbec...@nexbridge.com wrote: > The ITUGLIB project team maintains a port of GNU Make for currently > supported HPE NonStop Guardian platforms. We do intend to port 4.4 > when it is released. I am the official maintainer on the team, at > present. The HPE NonStop OSS (POSIX-compatible) platform port is > maintained by HPE Development as part of their "coreutils" project. > The latter's port tends to lag behind our port. I'm not familiar with the project names so can you be clear about which port(s) are used by HPE NonStop? Do both of these efforts refer to the VMS port? In specific, I'm looking at the "VMS" preprocessor variable and all the code ifdef'd using that, plus the extra source files such as vmsify.c, vmsjobs.c, etc. Is this what is used by the ITUGLIB project? Does the NonStop OSS port use these as well, or does it configure itself as a standard POSIX-style application and not use the VMS- specific code? > We do intend to port 4.4 when it is released. A release candidate for 4.4 was made a week or so ago and a second one will be made most likely this weekend. It would be great if someone could try those, that way we could resolve any issues found before the release, rather than after. However, I realize schedules don't always align so if it doesn't work that's OK.
Re: Deprecating OS support
> From: Paul Smith > Cc: bug-make@gnu.org, Juan Manuel Guerrero > Date: Sat, 01 Oct 2022 14:48:01 -0400 > > On Sat, 2022-10-01 at 20:42 +0300, Eli Zaretskii wrote: > > The DJGPP project has been routinely porting all versions of Make up > > to and including 4.3. > > By "DJGPP project" I expect you are referring to the MSDOS port (I'm > not familiar with all the alternative names). Yes. DJGPP is the MSDOS port of GNU development tools, based on GCC and GNU Binutils. > The thing that I'm specifically looking at in the code are ifdef's > using __MSDOS__. Are these the ifdefs used by DJPP? Yes.
Re: Deprecating OS support
On Sat, 2022-10-01 at 20:42 +0300, Eli Zaretskii wrote: > The DJGPP project has been routinely porting all versions of Make up > to and including 4.3. By "DJGPP project" I expect you are referring to the MSDOS port (I'm not familiar with all the alternative names). The thing that I'm specifically looking at in the code are ifdef's using __MSDOS__. Are these the ifdefs used by DJPP? If these ifdef's are used by an active port, then definitely they should be preserved. My real goal is to try to do some work to clean up the code in the next release: remove and/or simplify ifdefs, break up the source into separate OS-specific files, etc. Since I don't have access, myself, to all the different systems this is not always easy to do confidently. It would be nice if someone involved in the various porting efforts were available during the release candidate cycle and could report that the code compiles and works, for whatever definition of works they feel is appropriate, on the port(s) they care about before the release. But I realize that this is not always possible and I'm not requiring it in order to preserve the port. Just hoping :).
RE: Deprecating OS support
On October 1, 2022 1:03 PM, Paul Smith wrote: >With the upcoming release (4.4) I intend to announce that I'll be removing >support >for the following platforms in the next, post-4.4 >release: > > - OS/2 (EMX) > - Amiga > - Native MS-DOS > >For the first two, I suspect that whatever support we currently have is broken >and >it's not really possible to build GNU make, even today, for those platforms. I >haven't received any input from anyone using those platforms in years and it's >hard for me to believe that, with all the changes, everything still "just >works". > >I'm less sure about native MS-DOS. Maybe someone still uses this? > >If anyone thinks that any of these should be preserved and I should not >announce >deprecation for them, let me know. > >Obviously, versions of GNU make up to and including the upcoming 4.4 would >still >be available for those platforms (if they work). > >This would leave us with the following supported platforms, post 4.4: > > - POSIX-based systems > - Windows > - VMS > >For VMS I haven't heard from anyone about it this release cycle so I don't >really >know what the status is, but it was actively supported in GNU make 4.3. The ITUGLIB project team maintains a port of GNU Make for currently supported HPE NonStop Guardian platforms. We do intend to port 4.4 when it is released. I am the official maintainer on the team, at present. The HPE NonStop OSS (POSIX-compatible) platform port is maintained by HPE Development as part of their "coreutils" project. The latter's port tends to lag behind our port. Regards, Randall Becker
Re: Deprecating OS support
> From: Paul Smith > Date: Sat, 01 Oct 2022 13:02:55 -0400 > > With the upcoming release (4.4) I intend to announce that I'll be > removing support for the following platforms in the next, post-4.4 > release: > > - OS/2 (EMX) > - Amiga > - Native MS-DOS > > For the first two, I suspect that whatever support we currently have is > broken and it's not really possible to build GNU make, even today, for > those platforms. I haven't received any input from anyone using those > platforms in years and it's hard for me to believe that, with all the > changes, everything still "just works". > > I'm less sure about native MS-DOS. Maybe someone still uses this? The DJGPP project has been routinely porting all versions of Make up to and including 4.3. For the latest announcement, see https://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2022/06/07/17:09:13 > If anyone thinks that any of these should be preserved and I should not > announce deprecation for them, let me know. Juan (CC'ed) has been providing all the latest ports of Make, so I'll let him answer these questions.
Deprecating OS support
Hi all; With the upcoming release (4.4) I intend to announce that I'll be removing support for the following platforms in the next, post-4.4 release: - OS/2 (EMX) - Amiga - Native MS-DOS For the first two, I suspect that whatever support we currently have is broken and it's not really possible to build GNU make, even today, for those platforms. I haven't received any input from anyone using those platforms in years and it's hard for me to believe that, with all the changes, everything still "just works". I'm less sure about native MS-DOS. Maybe someone still uses this? If anyone thinks that any of these should be preserved and I should not announce deprecation for them, let me know. Obviously, versions of GNU make up to and including the upcoming 4.4 would still be available for those platforms (if they work). This would leave us with the following supported platforms, post 4.4: - POSIX-based systems - Windows - VMS For VMS I haven't heard from anyone about it this release cycle so I don't really know what the status is, but it was actively supported in GNU make 4.3.
