|
|
Subscribe / Log in / New account

Defining the Rust 2024 edition

Defining the Rust 2024 edition

Posted Jan 31, 2024 19:13 UTC (Wed) by pizza (subscriber, #46)
In reply to: Defining the Rust 2024 edition by Cyberax
Parent article: Defining the Rust 2024 edition

> I'm sorry, but do you understand the word "portable"? Autotools is supposed to make projects portable, so they can be used in all kinds of environments.

You're being facetious.

Windows code isn't portable or reusable with anything else. MacOS code isn't portable [1]. iOS anything isn't portable. Ditto Android. Every one of those platforms has a bajillion bespoke quirks and [mis]features, including mutally incompatible toolchains and build environments. The only "portable" code possible is stuff that is purely computational; everything else has to have some sort of bespoke interface to the specific platform being targeted, or you target a metaplatform (eg SDL, QT, or Unreal Engine 5) that abstracts away those platform differences for you. Even then, you're still nearly always stuck with a separate "project" for each target platform's bespoke build/toolchains.

Autotools only ever covered UNIX-ish platforms [2], which at least nominally attempted to adhere to a common specification. And autotools itself didn't magically handle those platform differences for you; all it could do is detect what was or wasn't available and adjust the build (or fail) accordingly. It was always incumbent upon to the software author to actually write non-trivial platform-specific code for themselves.

In other news, Cars can't drive on water, and trains can't fly. More than once, anyway.

[1] The GUI stuff was never portable; pure cmdline stuff is in theory, but it's grown more difficult in practice with each successive release.
[2] These days, most of the flexibility Autotools provides has been mooted due to the nearly-complete relegation of proprietary UNIXes to the dustbin of history.


to post comments

Defining the Rust 2024 edition

Posted Jan 31, 2024 19:48 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> You're being facetious.

No. I'm not. I'm saying that the traditional C-based infrastructure (C + autotools) is failing at the very basic level: it can't even be used on the most common OSes.

My personal most recent autohell-related nightmare was with building libtiff for iOS.

> The only "portable" code possible is stuff that is purely computational

Yet autotools fail even with that.

> The only "portable" code possible is stuff that is purely computational; everything else has to have some sort of bespoke interface to the specific platform being targeted, or you target a metaplatform (eg SDL, QT, or Unreal Engine 5) that abstracts away those platform differences for you. Even then, you're still nearly always stuck with a separate "project" for each target platform's bespoke build/toolchains.

But somehow, we can make that work with CMake. Not without issues, but it works, and I can use normal native toolchains (XCode/MSVS) with them.

Defining the Rust 2024 edition

Posted Feb 1, 2024 23:54 UTC (Thu) by dankamongmen (subscriber, #35141) [Link]

it required some effort (and, to be fair, our windows builder is currently reporting failure), but i was able to get Notcurses building on Windows and OSX using cmake and portable c. admittedly, it's not using GUI toolkits, but it's definitely a nontrivial, unix-first, non-pure-computational library.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds