Autodetect appropriate toolchain

[friedkiwi]

The Unix-based build script assumes GCC to build Open Watcom. However,
some operating systems (notably FreeBSD and Darwin/macOS) do not ship
with GCC anymore, resulting in the build failing.

This commit adds a rudimentary form of auto-detection based on the
host's uname value to determine a suitable default toolchain.

[ArmstrongJ]

I'm not sure I agree with just arbitrarily autodetecting the toolchain. If I wanted to use GCC on macOS (if I'm using a separate GCC install or I'm running on an older release), I'd need to comment out this entire block. Additionally, I use Open Watcom on Linux to build Open Watcom, and this autodetection will force GCC without commenting it out.

I think the current, well-commented line where you simply choose which toolchain manually is better. Perhaps if the autodetection was only triggered if nothing was selected, this change might be better. Or possibly a quick check to see if the toolchain is available before launching the build, producing an explicit error, might be okay.

[jmalak]

I understand your efort to improve OW build system.
But it is not intention to improve any such feature in standard build process, where control by TOOLCHAIN is only supported way.
Build system need some configuration in dependency on TOOLCHAIN and not all compilers and versions are supported on each preffered OW build platform. We need it for porting to other platforms.
Generaly if TOOLCHAIN is not defined then it is mistake. In this case for shell script it falls to Linux as prefered platform with gcc etc. Other NIX platforms are not preferred. You can build OW for Linux on Linux by OW, no on another NIX platforms. On these platforms OW bootstrap tools are compiled for build OW only. OW is cross compiled/build for other platforms only.
There are some limited architectures on which OW tools are build by native compiler but without support for this architecture, it is cross compile tools only. By axample ARM architecture (Rapsbery Pi) native cross development OW tools for other architectures (no support for ARM).
Fall back to some default is only help for begginers but for preffered platforms only.
Preffered build platforms are 32-bit DOS, 32-bit Windows, OS/2 and Linux which are OW supported platforms.

[jmalak]

Anyway build system was improved to use only OW and POSIX tools on all preffered platforms.
There is posix project where simple implementations of POSIX tools are located and these are build on platform which don't have native posix tools.

[friedkiwi]

I'm not sure I agree with just arbitrarily autodetecting the toolchain. If I wanted to use GCC on macOS (if I'm using a separate GCC install or I'm running on an older release), I'd need to comment out this entire block. Additionally, I use Open Watcom on Linux to build Open Watcom, and this autodetection will force GCC without commenting it out.

I think the current, well-commented line where you simply choose which toolchain manually is better. Perhaps if the autodetection was only triggered if nothing was selected, this change might be better. Or possibly a quick check to see if the toolchain is available before launching the build, producing an explicit error, might be okay.

I agree with the 'nothing is selected approach', and if you're okay with that, I'll implement that? Both macOS and FreeBSD do not have GCC installed by default if you install the development tools (they ship with clang/llvm), so just running the script without editing it would result in a hard fail.

[jmalak]

Yes it will fail because it is not preffered platform.
It is reason why TOOLCHAIN must be defined and user need understant what is doing.
All non preffered platforms doesn't has standard OW support (you can not create executable for them by OW),
Therefore it is not for begginers, because build version of OW is not usable on such platforms.
Until such platforms will be fully supported (OW will be ported to such platforms) it can not have standard OW support in OW build system.
I don't want enable begginers to work with such platforms by default.

[jmalak]

Generaly we are able to build OW on any POSIX system, but created OW is not usable on such system until OW port will be done for appropriate system.

[Wohlstand]

What about NetBSD and OpenBSD?

[bubach]

Why not just set CLANG as default, who even uses GCC anymore, stallman?

Btw, the build process on macOS seem to work surprisingly well - only issues I had before the build actually got started was some realpath cmd missing, but simply pwd without it worked fine. Also, the first few minutes into the build it gave me a shitload of warnings due to pragma pack syntax. Not sure I'm up for any attempts at pull requests yet, but thought you should know.

[jmalak]

Thanks for your notes.
We use gcc because it is supported from beginning. Clang support was added later and is relatively new.
Anyway GNU based systems (most Linux distributions) use gcc by default.

Take into account, OW is cross-compiled on macOS, but can not be used to create macOS native application.
macOS as platform is not supported, because OW is not ported to macOS (run-time libraries etc.).
Only bootstrap tools are compilable on macOS (but need macOS native tools).

[XVilka]

By the way, you can setup SourceHut CI jobs that supports FreeBSD and OpenBSD (and hopefully NetBSD in the future):

• https://man.sr.ht/builds.sr.ht/compatibility.md#freebsd
• https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd

[zoomosis]

I believe for almost all Linux distros, cc will be a symlink or hardlink to gcc on Linux, and c++ a link to g++.

On modern versions of FreeBSD, cc hardlinks to clang and c++ to clang++. I assume it's the same for MacOS.

So unless I'm mistaken it should be safe to just use cc and c++ on *nix systems instead of trying to detect what to use.

[jmalak]

Good point.
The problem is mainly with OW C++ compiler and code which use old language standard and for non-Watcom compiler requires to setup exact Compiler Language standard.
I am afraid POSIX standard doesn't specify options for such Language standards control.
Also OW build need alignment control in some code that it is not well portable and not ISO C feature.
Most of code has removed dependency on alignment control but use of cc or c++ will require review of source code for such construct.