Defining the Rust 2024 edition

Posted Jan 31, 2024 17:48 UTC (Wed) by LtWorf (subscriber, #124958)
In reply to: Defining the Rust 2024 edition by Cyberax
Parent article: Defining the Rust 2024 edition

I mentioned osx, not ios.

If you develop for ios using native stuff, you are not doing anything that will ever be portable, so why would you use autotools, a tool aimed at portability?

Defining the Rust 2024 edition

Posted Jan 31, 2024 17:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

> I mentioned osx, not ios.

Both have similar issues, especially when you want fat binaries to natively support x86_64 and arm64.

> so why would you use autotools, a tool aimed at portability?

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.

Yet they fail miserably for the most commonly used operating systems.

Defining the Rust 2024 edition

Posted Jan 31, 2024 18:56 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (5 responses)

> I'm sorry, but do you understand the word "portable"?

I understand perfectly, but I'm sure you know very well that autotools isn't magic and if you link 25 libraries that are unique to ios, your application isn't going anywhere else anyway. So why would you want to use a tool for portability while writing an intrinsically non-portable application?

Ah yes, to make "gotcha, i'm so clever" comments.

Defining the Rust 2024 edition

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

> So why would you want to use a tool for portability while writing an intrinsically non-portable application?

No. I'm not talking about making an iOS app portable. I'm talking about simply _consuming_ third-party libraries that use autotools in an iOS application. You know, the whole reason for the existence of autotools.

Yet they fail even with this very basic functionality.

Meanwhile, using Rust with Cargo is seamless, even for more complicated scenarios.

Defining the Rust 2024 edition

Posted Jan 31, 2024 19:44 UTC (Wed) by pizza (subscriber, #46) [Link] (3 responses)

> No. I'm not talking about making an iOS app portable. I'm talking about simply _consuming_ third-party libraries that use autotools in an iOS application. You know, the whole reason for the existence of autotools.

Please enlighten us how one can build an iOS application or library using anything other than XCode.

Defining the Rust 2024 edition

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

Have you used CMake?

You write CMakeFiles to describe your library and deps, and then generate an XCode project from it. On Windows, you can generate an MSVS project.

Defining the Rust 2024 edition

Posted Feb 4, 2024 14:01 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> You write CMakeFiles to describe your library and deps, and then generate an XCode project from it. On Windows, you can generate an MSVS project.

But.. that's still using XCode/MSVS?

If the complaint is that the full autotools suite doesn't generate anything other than pure makefiles, that's a technical problem that can be rectified by someone willing to put the work into said feature. [1]

FWIW, a quick bit of googling shows several folks successfully generating iOS libraries for autotools-based projects -- It's effectively just another cross-compile target. But each (major) iOS/etc version (and sometimes hardware family on top of that) requires a different target tuple and toolchain options that are not easily discoverable, and you need to rinse and repeat multiple times to generate all of the variations that XCode needs. Which is a real PITA.

[1] Granted, it's unlikely that folks with high levels of autotools know-how are motivated to add support for probably the most FOSS-hostile platform widely deployed today. And adding Windows support requires a _lot_ more work than just changing the build system.

Defining the Rust 2024 edition

Posted Feb 4, 2024 14:52 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> But.. that's still using XCode/MSVS?

Not quite. The build description remains in CMake. XCode/MSVS are used to work with the code.

> If the complaint is that the full autotools suite doesn't generate anything other than pure makefiles, that's a technical problem that can be rectified by someone willing to put the work into said feature. [1]

No. It can't be reasonably done in autotools without making them into CMake. It's possible in the same sense as all Turing-complete languages can emulate each other.

> FWIW, a quick bit of googling shows several folks successfully generating iOS libraries for autotools-based projects

Try it for real. It JustDoesntWork without tons of fiddling.

Defining the Rust 2024 edition

Posted Jan 31, 2024 19:13 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> 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.

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.