Defining the Rust 2024 edition
Defining the Rust 2024 edition
Posted Jan 30, 2024 23:17 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)In reply to: Defining the Rust 2024 edition by LtWorf
Parent article: Defining the Rust 2024 edition
Autotools don't work on native Windows and barely work on macOS. But yeah, they would allow you to run your application on HP-UX from 1995!
Posted Jan 31, 2024 10:16 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (12 responses)
Posted Jan 31, 2024 15:41 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Posted Jan 31, 2024 17:48 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (10 responses)
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?
Posted Jan 31, 2024 17:51 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
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.
Posted Jan 31, 2024 18:56 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (5 responses)
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.
Posted Jan 31, 2024 19:27 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 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.
Yet they fail even with this very basic functionality.
Meanwhile, using Rust with Cargo is seamless, even for more complicated scenarios.
Posted Jan 31, 2024 19:44 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
Please enlighten us how one can build an iOS application or library using anything other than XCode.
Posted Jan 31, 2024 19:49 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 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.
Posted Feb 4, 2024 14:01 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
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.
Posted Feb 4, 2024 14:52 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Jan 31, 2024 19:13 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
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.
Posted Jan 31, 2024 19:48 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Feb 1, 2024 23:54 UTC (Thu)
by dankamongmen (subscriber, #35141)
[Link]
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
[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
Defining the Rust 2024 edition