Open visual studio (or Qt) 'File' menu, 'New C/C++ project'. Press F7 to compile.
No command line, no cargo build, no cargo run, no cargo.toml. Just press the green "play" button and your full graphic application shows up.
Embedded with Arduino C++: 'file' menu, then 'new sketch', click the arrow to compile and download to the board.
0. Export/upload my source
1. Import/download my remote source
2. Compile my source for different targets
3. Cleanup my source and my compiled source
5. Do all the above for different versions/locations of my source
6. Do all the above for source not my own
7. Do all the above with a simple command and or a simple key->value in a config file
Then I need to do all the above with
8. using a terminal on my personal computer
9. on a remote server using ssh'ed terminal
10. in a script automation file like a docker file or maybe a vim script that setups my dev environment
11. Have 0 - 10 be so easy to do, basically a simple command or two, that I don't have to spend days figuring out tooling FOR EACH TASK and googling mystical error messages for solutions on obscure forums posted 2009.
I stayed with Rust because it has good tooling. Because it's the one thing that hasn't driven me insane at one point or another. I wanted to program in Haskell and c, but I am so sick of the terrible tooling and the terrible conventions of the communities (something Go at least gets right) that I instead program in Rust, a language I enjoy less for it's merit as a language.
I haven't mentioned conditional compilation.
I haven't mentioned respecting the configuration options of dependencies.
The tooling has to at least do all that using the same syntax for commands and configuration. It has to be predictable enough that I can almost figure it out myself. No black magic.
I work mostly in IDEs and won't use the clunky command line if I have an alternative. After all, it's the year 2022. Why working like it's 1991? I don't want to spoil you the end of the movie, but I have this hunch that graphical user interfaces are the future.
And I don't see what you can't do with VS or Qt. Maybe setting up your toolchain with a script or using terminals (which I don't know what have to do with programming IDEs).
I do most of the above with fricking KEIL uVision for a myriad of microcontrollers!
I compile and edit whole Android OS with VSCode and the integrated SSH terminal! (I hate to use the command line, though!).
Cargo add pkgname on my computer.
Cargo add pkgname on a ssh session.
Cargo add pkgname in a docker script.
Wow the same process for doing it on my dev pc is the same everywhere else! Amazing. What do you do to automate deployment? ssh in and install your whole graphical tool then write a mouse macro to click the compile button?
You are taking a vacation with a U-Haul truck filled with your furniture. I am taking a vacation with a backpack.
There is no need for ssh’ing or recompiling.
For embedded I just give a bin file with everything in it. Use your favorite flashing tool.
For the rest, I can make an installer right from the ide. You know, the kind of 3 click installers the whole world is used to in 2022. An installer I can give grandma. Huge success from the 90’s.
Or maybe redistribute my program with a mobile app market. I can do that from my ide too!
Or maybe I’ll just handle a zip file with everything in it.
I’m afraid you can’t see it’s YOU who are in a niche, and not the other way around.
Just email me a binary to flash with a usb stick? Here's a link to download a zip file, just drag and drop into file explorer. Totally scalable stuff. But then again you just make calculators for the android app store, so I guess you're fine.
Dont make the mistake of thinking you are better than others, otherwise you’ll keep feeding the general feeling of Rust cultism and you’ll end up programming in niche languages from the command line, 1991 style.
And you mentioned "boomers" so I know exactly with who I am talking to.
My ego walks away unharmed from this conversation.
I believe you have a capable need for the tools you choose to use. I wish I could have sympathized, but the snark you engaged with set the wrong tone.
On Windows: download shared from here(1), unzip anywhere. Right click on the project, select "Project settings" (IIRC) then point to .libs you want to use (or add them all), add include path (ffmpeg/include). Done.
On linux (Qt): install with apt-get. Point to libs, add include path (in the .pro file).
The only complication is that you have to wrap the #includes with extern "C" {} if you are on C++.
I did it for both platforms the other day and it works. Super easy.
Cross-compile: on Qt you do it through packs you select at install stage. Sometimes it requires the runtime to be installed (like for Android) but it's not complicated.
On VS, I don't know today. I remember for Windows CE you had to install an SDK, and compilation/debug was out-of-the-box (F7 to compile, F5 to debug in-target). And I used Platform Builder for years, and I cross-compiled the entire OS from the menu.
On Arduino: select your board from the menu. Also, installing libraries is done through a menu. Pulled from online resources automatically.
But I guess I will not convince you. You'll come up with another challenge.
I also remember that I took the "hard" path on Linux and rebuilt ffmpeg, but it was like "git clone", "./configure", "make", "sudo make install". I had to use the command line, but nobody died (being a huge C project and all that).
But we were talking IDEs vs command line and "actually understand your development tool chain in C as well as C++". Of course that niche, worst-case project are going to require more complicated steps. The thing is that the command line and clunkyness is being forced onto the other 99% of the cases too, for simpler projects and dumber persons like myself.
I consider them to be the best case because everyone wants them so there has been some improvement down the road. I think Cyph0n pick a wrong example for that reason.
> I also remember that I took the "hard" path on Linux and rebuilt ffmpeg, but it was like "git clone", "./configure", "make", "sudo make install". I had to use the command line, but nobody died (being a huge C project and all that).
That is a happy case for the reason I've said before. In my experience many libraries do not build that cleanly, it is a routine challenge to determine which flags I have to put to configure or which library I have to install (that might not exist in my distro so I may have to build them as well). Also `sudo make install` alters the global environment, which is never a great idea in Linux distros; so you have to either make sure to run `./configure --prefix=$HOME` or likes, or just run `make` and pick necessary bits out of the build directories yourself. The latter is painful, but the former risks two competing versions of the same library in the global environment.
Honestly though this experience greatly depends on tasks, and you may have barely hit those worse cases in your life. The Windows SDK and Android SDK you've initially cited are two examples where almost everything is available for you and you don't need as many libraries to continue on.
[dependencies]
# Safe Rust wrapper
ffmpeg-next = "5.0.3"
[dependencies]
# Direct FFI bindings
ffmpeg-next-sys = "5.0.3"
And thanks to the build script maintained by the crate (library) owner, this process should work exactly the same across major OSes and architectures transparently.
Edit: Here is the relevant part of the build script that actually configures and builds libav based on Cargo feature flags and configured rustc OS + arch: https://github.com/zmwangx/rust-ffmpeg-sys/blob/499fca3630fb...
https://github.com/zmwangx/rust-ffmpeg/wiki/Notes-on-buildin...
And "Install FFmpeg (complete with headers) through any means, e.g. downloading a pre-built "full_build-shared".
Come on...
As for libav itself, if prebuilt libraries are not present, the build script will fetch the source and build it as a static lib.
Cargo is very opinionated, forcing upon you certain directory structures and even a default VCS. If you have a large project, cargo makes you jump through hoops. Building multiple binaries and libraries from one project is a pain, and has to be done exactly as cargo wants.
In terms of being able to "just get started", I think `gcc app.c` is way easier than using cargo. But that's not really important. You're not going to replace a million line C project with Rust just because "getting started" was a few seconds faster/slower.
No, it expects source code in `src` like most C/C++ projects anyway. Then it's `lib.rs` or `main.rs`. The opinionated directory structure (`pkg.rs` or `pkg/mod.rs`) is rustc not cargo.
> even a default VCS
Because it's the one used by most projects. Anyway, nothing prevents you from using mercurial, svn, ...
> Building multiple binaries and libraries from one project is a pain
Have you heard of Cargo workspaces? Because I've had no troubles with it.
> I think `gcc app.c` is way easier than using cargo
Agree to disagree. Because really soon, you'll want to manage dependencies.
In C/C++ there's no expectation of the code being anywhere.
> Because it's the [VCS] used by most projects.
I don't see how a VCS being popular is a reason to require it. It's not even "essentially all projects", just "most projects".
Neither do the authors of cargo:
`cargo new --vcs none`
That's not what I said. I said that most project do it this way anyway, regardless of any expectations. So who cares?
> I don't see how a VCS being popular is a reason to require it.
It is not required.
C & Rust come from different eras of easy-getting-started, IMO:
C - I just want to get shit done, I'm not taking on any dependencies, I'll just write it myself and sure it won't be the best but it'll do what I need and keep it simple;
Rust - I just want to get shit done, surely there's a lib for this and that, I can just glue them together.
So with Rust that's no harder to do than doing anything at all; with C it's quite a bit harder but also a bit easier if you don't.
Agreed that's not going to hold any weight in deliberating switching a million line project, but I do think it matters what hobbyists/spare-timers are using, what people want to work with, etc. Slowly.
(E.g. my day job is mainly python; if we needed something highly performant or embedded or whatever I'd be way more comfortable in Rust than ropey university-C.)
https://doc.rust-lang.org/cargo/reference/cargo-targets.html...
For packaging, you want your dependencies to be packaged as well, with build system using system-wide versions instead of pulling things from Cargo, with proper dynamic linking. There are several tools that help you manage that for Rust, Debian has some packaging helpers too, but it's pain nevertheless once you have to, say, support multiple crate versions in your code to deal with stable distros. Some of these troubles come more from the ecosystem than the tooling itself.
To some extent, I see that more as "Distros have ossified around the workflows and tooling that is essentially 'a third-party package manager like Conan for C++, but for C'".
How do you deal with the same monomorphization problems in C++ libraries? See https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx...
How do you deal with vendored single-header libraries and bespoke implementations brought about by C's lack of a cross-distro, cross-platform dependency handling story? You generally don't.
https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-...
As that article points out, Rust's approach to package management allows things to be shared between projects which, in practice, don't get shared between C projects.
With Crates.io not allowing existing crate versions to have their contents modified and Cargo.lock providing a SHA256-verified record of the exact dependencies your project used, you've got a record of what build dependency versions went into your package, which can be used by tools like `cargo audit`.
Yes, it means that you need tooling to automate rebuilding the binaries whenever they're statically linked but, as Michał Górny pointed out in 2012, that's already necessary with libraries that use C++ templates and, as was said in "Let's Be Real About Dependencies", "On the flip side, I wonder how many times vlc’s XML parser has been fuzzed?"
While it's slow going, discussion and an experimental prototype do exist for embedding full dependency versioning information inside Rust binaries to further help that approach: https://github.com/rust-lang/rfcs/pull/2801
Then add configuration options for conditional compilation, and a build system to define them properly.
Then use the configuration options of your dependencies in your build system.
Finally, repeat this process for every project and make sure you use the same syntax/api for your build system so you don't have to relearn everything everytime.
cc main.c is as easy as it gets when you rewrite everything from scratch.
cargo is as easy as it gets when you want an ecosystem.
Still, yes it's a bit more complicated. But can we not pretend that the non-existent toolchain in C/C++ is easier in 99% of use cases?
[0] - https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...
Once you solve this problem, C++ & CMake are of similar complexity for C++ dependencies.
Otherwise to compare C++ toolchains, if it's distributed as a .a file, just adding -l/path/to/libclosed.a works for C++, can't get more simple than that. Or one line in the CMake file with basically the same thing.
RUSTFLAGS="--extern closedlib=path/to/libclosedlib.rlib"Most software have dependencies that should be managed, linked in, figure the header file path of etc. Most software consists of several files which you don't want to re-build every time you change just 1 file (unless you change compiler flags etc.). It's a very tiny step from your example until the C or C++ toolchain becomes far from easy.
How do you mean? Where?