Re: Re-visited: No OpenWatcom in 4.1.0
- Posted by ghaberek (admin) Apr 03, 2023
- 533 views
This was a deliberate choice. OpenWatcom was dropped because, at the time, we had recently introduced 64bit support, OW did not have it (yet), and we thought we would release very soon. That was ... a decade ago?
Nowadays, OW has had 64bit support for a long time ( see https://www.japheth.de/JWasm.html ) so perhaps it makes sense to revisit this decision.
Agreed. I think Shawn's suggestion of de-platforming the build system would be the path forward here: https://openeuphoria.org/forum/136852.wc. Most of the "E" macros used in the backend like EWINDOWS, ELINUX, etc. can be replaced by mostly-portable "standard" macros like _WIN32, __linux__, etc. and unique platform/architecture/compiler settings (like Watcom/GCC gotchas) should live in euphoria.h (which is used by the translator) and the translator itself should be stripped of any platform requirements and accommodations altogether. Historically I think a lot of this was in place because Rob was working what was available at the time, and modern C tooling has come a long way in the twenty years since the translator was released. I also think the translator could be greatly simplified in both its internal complexity and the complexity of its output, and we could/should rely more on compiler flags/optimizations instead, but that work is much further down the road. And as I mentioned in Shawn's thread from last year, I'd also like to bundle TCC with Euphoria to be the "default" compiler for translating code. This would be further assisted by cleaning up and generalizing the translator's compiler support.
-Greg
