Path: csiph.com!1.us.feeder.erje.net!3.us.feeder.erje.net!feeder.erje.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: arnold@freefriends.org (Aharon Robbins)
Newsgroups: comp.compilers
Subject: Re: Portable Software (was: fledgling assembler programmer)
Date: 28 Mar 2023 14:42:18 GMT
Organization: non
Sender: johnl@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <23-03-032@comp.compilers>
References: <23-03-001@comp.compilers> <23-03-017@comp.compilers> <23-03-022@comp.compilers> <23-03-029@comp.compilers>
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="71395"; mail-complaints-to="abuse@iecc.com"
Keywords: tools
Posted-Date: 29 Mar 2023 04:46:09 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Originator: arnold@freefriends.org (Aharon Robbins)
Xref: csiph.com comp.compilers:3433


In article <23-03-029@comp.compilers>,
Hans-Peter Diettrich  <DrDiettrich1@netscape.net> wrote:
>My impression was that the FSF favors C and ./configure for "portable"
>code.

Like many things, this is the result of evolution. Autoconf is well
over 20 years old, and when it was created the ISO C and POSIX standards
had not yet spread throughout the Unix/Windows/macOS world. It and the
rest of the autotools solved a real problem.

Today, the C and C++ worlds are easier to program in, but it's still
not perfect and I don't think I'd want to do without the autotools.
Particularly for the less POSIX-y systems, like MinGW and OpenVMS.

>Can somebody shed some light on the current practice of writing portable
>C/C++ software, or any other compiled language, that (hopefully) does
>not require additional human work before or after compilation for a
>specific target platform?

Well, take a look at Go.  The trend there (as in the Python, Java and
C# worlds) is to significantly beef up the standard libraries. Go
has regular expressions, networking, file system, process and all kinds
of other stuff in its libraries, all things that regular old C and C++ code
often has to (or had to) hand-roll.  That makes it a lot easier for
someone to just write the code to get their job done, as well as
providing for uniformity across both operating systems and applications
written in Go.

Go goes one step further, even. Following the Plan 9 example, the
golang.org Go compilers are also cross compilers. I can build a Linux
x86_64 executable on my macOS system just by setting some environment
variables when running 'go build'. Really nice.

The "go" tool itself also takes over a lot of the manual labor, such
as downloading libraries from the internet, managing build dependencies
(no need for "make") and much more.  I suspect that that is also a
trend.

Does that answer your question?

Arnold