Defining the Rust 2024 edition
Defining the Rust 2024 edition
Posted Jan 30, 2024 13:07 UTC (Tue) by LtWorf (subscriber, #124958)In reply to: Defining the Rust 2024 edition by khim
Parent article: Defining the Rust 2024 edition
Do you think there are many gnu/linux users who do not use distributions?
Isn't a distribution a common enough use-case that we should keep it into account? Since it accounts for roughly 100% of the users.
Posted Jan 30, 2024 13:35 UTC (Tue)
by khim (subscriber, #9252)
[Link] (29 responses)
Sure. It's not as if I have a choice: C/C++ world have never managed to create useful enough packaging tool (there are Vcpkg and Conan but there are just way too many packages that are not available in either of them and, worse, many C/C++ libraries developers don't like when you use these). But these days I tend to just import the majority of libraries via Why should we? C and C++ are weird exception, most other, more-or-less modern languages have much better alternatives. At least they don't force you to learn different commands for the exact same thing if you develop for different platforms. What kind of joke is that? The majority of development happens on Windows and any solution that doesn't adequately work on Windows is just simply non-starter. And MacOS support is nice to have, too. That's why even C/C++ world dropped autotools and switched to CMake. Which is also awful (in some sense even more awful, that autotools), but at least it's cross-platform. Cargo is also cross-platform and I don't see how people would go from there to distros (except when forced by some rules in government contract or something like that). Tomorrow… tomorrow situation maybe different. Who knows, maybe supernova explosion would make half the Earth sterile and thus would halt Windows development. Then distributions may become more impoertant and would even gain 100% of users. But today… today it's Windows, MacOS, Linux. In that order. And Linux, for the majority, is WSL.
Posted Jan 30, 2024 16:08 UTC (Tue)
by bluca (subscriber, #118303)
[Link] (6 responses)
Posted Jan 30, 2024 17:07 UTC (Tue)
by khim (subscriber, #9252)
[Link] (5 responses)
Sure. Linux ( Why would they they do that? You only would need to do that if Linux would be demoted to Tier2 (or Tier3). But to make that ploy with distributions work you have to remove Tier1 status from Windows/MacOS and that would be bad idea. Autotools tried that and are now considered “legacy” by most C/C++ developers.
Posted Jan 30, 2024 20:12 UTC (Tue)
by bluca (subscriber, #118303)
[Link] (4 responses)
Posted Jan 30, 2024 20:47 UTC (Tue)
by khim (subscriber, #9252)
[Link] (3 responses)
You either support all Tier1 platforms identically (which, actually, makes them Tier1 platforms) or you embrace the differences and then one of them becomes Tier1 and all others become Tier1.1 or Tier1.5. And, well… Linux distros… All other popular platforms offer an SDK and the ability to install binary, compiled with the use of said SDK, but in case of Linux “wget | bash” is the closest thing to that (note that there are not And, well… if there are no better options then this one would be chosen. It's as simple as that.
Posted Jan 31, 2024 11:35 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (2 responses)
Posted Jan 31, 2024 12:04 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
How may it work, otherwise? Support tier is quite literally defined by the set of things guaranteed to work on a given platform. Here are the rules. If different platforms are treated differently then how may you even claim they all are “first class”? What does “first class support” even mean if you provide different guarantees for different “first class” targets? How can you justify calling that “first class support” if things are not treated the same?
Posted Jan 31, 2024 16:43 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Because all platforms are not the same?
Women and men do not like being treated "the same" - treat a woman like a man and you'll get the cold shoulder or a slap round the face!
First class support means they are treated FAIRLY. If two platforms provide different support TO YOU, you cannot treat them THE SAME back. It's just not possible. But you can still treat them fairly.
We know what you're trying to say. But arguing "ad extremis" just hurts your own cause!
Cheers,
Posted Jan 30, 2024 22:40 UTC (Tue)
by LtWorf (subscriber, #124958)
[Link] (21 responses)
You want to make me believe that 99% of the software present on your computer doesn't come from distribution packages?
For people who aren't yourself, your software isn't any more important than all the other software they use. Possibly it is even less important. They don't want to manually update your software specifically. They want autoupdates, default configurations, and so on.
You are quite uninformed about autotools. The whole point of it is to have portability. cmake covers a lot of common cases, but you might be in a situation where cmake lacks some features that autotools have. I've never encountered a feature that cmake has and autotool doesn't have.
People like repositories… what they don't like is to treat every single program as a special butterfly. In that case they will just not use it, unless it's needed for work, in which case they will put up with the pain.
Posted Jan 30, 2024 23:17 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
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]
Posted Jan 31, 2024 1:09 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
Why would it come from distribution packages? They don't support Windows and don't support macOS, either. So neither my game rig nor work computer have that many distribution packages. Sure, ditribution-provided packages are important for WSL viability and use with docker image on macOS that I need to develop some software, but in the grand scheme of things I don't need that many distro-provided packages for that. And if I want only to use some software then I can, finally, use the version of LibreOffice I like and version of GIMP I like without thinking about crazy dilemma of whether it's a good idea to upgrade every single app just to get that new feature in one of them. You just have to accept that Linux on desktop have arrived — only it arrived in a form WSL. And it's now merely a tool for software development for various non-desktop platforms. That changes dynamics significantly. The only problem with that reasoning is that Linux distros today, for the majority of people are firmly in the something needed for work, which you have to use despite all the pain it causes. Distros were born in times when Internet was expensive to solve the problem which haven't existed for decade or more: how to efficiently distribute software that software maker couldn't send from their web site. Hence the name. Today they are no longer needed and just cause needless friction and pain (although if you have to develop software using GNU-based tools they are often indispensable): they impede delivery of apps from developer to your system, they tie various software packages into one huge bundle (kinda-sorta solvable if you use Gentoo, but even there it's quite painful to update one single package), they are very much a solution in a search of a problem. Seriously? Show me how can I can create a trivial “Hello world” program and we'll go from there. Assume I'm typical developer and thus pick platforms to support from this list. Which means I have to support Android, Windows, iOS, OS X before I would think about supporting Linux. And if I'm typical developer then I would, of course, use Visual Studio Code or maybe CLion, or, perhaps, even Visual Studio proper (although Visual Studio Code is more popular novadays). CMake support all the things that matter (but fails in 1% of fringe cases), autotools solve perfectly lots of fringe cases that I don't care about while ignoring 90% if not 99% of cases which people actually care about.
Posted Jan 31, 2024 10:16 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
You went from using a distribution one comment above to not using one. Anyway brew and WSL are/use distributions.
Also, if you use the apple app store you are using a (non-free) distribution.
Also, I'm sure your work uses gaming rigs and osx for servers right?
You are argumenting for the sake of argumenting, knowing fully well that what you are saying makes no sense.
Users want distributions. They don't want to install your special PGP key for your special archive for your special software, of which you will proceed to lose the private key breaking automatic updates for everyone. They want the whole system to just do its thing and keep working.
> Show me how can I can create a trivial “Hello world” program
Why not a "return 0" directly if we want to make useless examples?
> autotools solve perfectly lots of fringe cases that I don't care about
if your software has the complexity of "hello world", yes I agree that you should not use autotools. But you should probably also abstain from giving advice trying to pass as an expert in portable software, when in reality you only develop trivial software for one single platform.
In the end, it seems you will argue anything and its opposite just to argue, and I have the feeling you've even forgotten what you were arguing for, so I'll stop this futile exchange.
Posted Jan 31, 2024 11:54 UTC (Wed)
by khim (subscriber, #9252)
[Link]
It's always your choice, but no, I haven't forgottten (if, maybe, you did). Let's do quick summary, shell we? And here we have bunch of half-truths that you use to try to derail the discussion While 100% truth on the surface in reality it doesn't support you cause. Yes, the majority of people only want the whole system to just do its thing and keep working… but no, they don't want to see shared libraries (or anything else) being silently upgraded behind their backs! Internet is full of tutorials which people are using to stop these updates that developers and OS makers shove down their throats. And most user never upgrade anything unless forced or unless they know what they get after update (not much these days, times when new versions were sold for money and actually had to demonstrate some kind of viability are gone) You don't need shared libraries or stable ABI to never upgrade. Here's typical story from the “what real users want”. They just want things that work. Nothing less, nothing more. Who said I only develop trivial software for one single platform? Software I develop actually is used on most platforms: Windows, MacOS, Android, ChromeOS, even Linux! It's not used on iOS, which makes me a bit atypical (most developers would care about iOS before they would think about ChromeOS), but not too much. You, on the other hand, are trying, repeatedly, to ignore with prejudice 99% of the picture (most popular OSes and most users) and only concentrate on one, very fringe, case. You say it with such an extreme conviction like just sprouting these words would make them true. But most users don/t even know what PGP key is and would definitely not try to install it even if told. They know how to click on link and select the checkbox, though. That's what they expect and that's what they get in the majority of use cases. Another truth designed the muddle the water: yes, Windows store and Apple's App Store may be classified as “distributions”, if you squint just right, but they don't need shared libraries (and they actually provide stable ABI to app developers while the majority of Linux distros still refuse to do that). True, but, most of the time, in modern world, they are glorified package managers for C and C++ packages. It's entirely not clear why some other language which, unlike C or C++, already have a standard package manager should deal with them. Sure, if someone wants/need to merge Rust packages and compiler into these distros then they can do that. It's free world and licenses permit that. But it's entirely not clear why Rust developers should spend time and money supporting something they don't need or want.
Posted Feb 2, 2024 13:01 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Supporting MSVC as a compiler[1]? C++ modules support is also something I'm interested to see how autotools will support (I implemented it in CMake; there are things that really need proper modelling that autoconf doesn't provide AFAIK).
FD: CMake developer
[1] The FAQ still has this as a TODO at least: https://www.gnu.org/software/automake/faq/autotools-faq.h...
Posted Feb 2, 2024 13:02 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Feb 2, 2024 16:44 UTC (Fri)
by khim (subscriber, #9252)
[Link]
With Kati this should be possible, someone just need to intergrate it into all that automake machinery to teach it to properly rebuild ninja files when that's needed. Not sure if anyone have ever done that or not, though.
Posted Feb 2, 2024 15:52 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
All C++ build tools suck, but CMake at least works properly. And the backwards compatibility is great.
> Do you not use a distribution?
Defining the Rust 2024 edition
git submodule approach.Defining the Rust 2024 edition
> But AFAIK not only it's not made, but it's touted as a first-class citizen in terms of support.
Defining the Rust 2024 edition
x86-64 and arm) is Tier1 target. But so are Windows 7+ and MacOS 10.12+.Defining the Rust 2024 edition
Defining the Rust 2024 edition
sudo, BTW).Defining the Rust 2024 edition
> There's actual no reason why first-class support requires the exact same identical thing to be done everywhere.
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Wol
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
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
> You want to make me believe that 99% of the software present on your computer doesn't come from distribution packages?
Defining the Rust 2024 edition
Defining the Rust 2024 edition
> In the end, it seems you will argue anything and its opposite just to argue, and I have the feeling you've even forgotten what you were arguing for, so I'll stop this futile exchange.
Defining the Rust 2024 edition
Defining the Rust 2024 edition
Defining the Rust 2024 edition
> I'm sure auto*conf* could be coaxed into doing this, but I have no idea how one would automatically port any auto*make* usage to it.
Defining the Rust 2024 edition
Defining the Rust 2024 edition