I work mostly in terminal and won't use clunky IDE programs. I need to be able to

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.

Mind you I haven't even mentioned the complexities involved in making dependencies optional, platform specific.

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.

You have to do a lot of things. I don't envy you at all!

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

The point of not strapping a clunky IDE to my workflow is that a terminal offers flexibility and mobility that I (and everyone who programs in 2022. Maybe not you tho) need to fulfill line items 0-10.

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.

It seems we don’t go on vacation to the same places.

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.

App store? A windows installer? So you just make user apps? Then publish them on existing platforms built by programmers who had to think about all the complexities you blissfully pretend don't exist?

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.

Nope. I do embedded C/C++ and what you can read above. I occasionally do some tooling for desktop or low level APIs. But I know what ides are capable of.

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.

You are really obsessed with this 1991 stuff. And here I thought the common prejudice was that only boomers were still stuck using IDE programs. I think you believe yourself to be in an ego battle and that's just not the case for me.

I was discussing "work you have to do to setup and actually understand your development tool chain in C as well as C++", and I mentioned IDEs' easy of use. Then you came along saying that the command line is the way for "everyone who programs in 2022"... which is clearly the opposite. If you don't want to see that... I'm sorry but this conversation doesn't have a point.

And you mentioned "boomers" so I know exactly with who I am talking to.

My ego walks away unharmed from this conversation.

Actually, I did not start by mentioning anything about years or what is up-to-date. You were the first one to bring up 1991 and current year as a derision.

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.

Now walk us through how you would use a relatively large library in your new project (e.g., libav or boost). And then show us how to cross-compile both for another OS + arch.

libav:

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.

(1) https://github.com/BtbN/FFmpeg-Builds/releases

You have just (inadvertently) demonstrated the exact problem: if you don't have a pre-built binary your job is significantly harder. But everyone knows that and most popular libraries do have a pre-built binary officially or unofficially. That makes this kind of discussion harder, because someone is talking about the worst case and another (in this case you) is talking about the best case.

Parent gave two "big libs" as an example (was it a "worst case"?), I choose the one I used the other day and I remember how I used it.

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.

> Parent gave two "big libs" as an example (was it a "worst case"?), I choose the one I used the other day and I remember how I used it.

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.

Just to compare, here's how you would add the latest version of libav to a Rust project using Cargo:

  [dependencies]
  # Safe Rust wrapper
  ffmpeg-next = "5.0.3"

or

  [dependencies]
  # Direct FFI bindings
  ffmpeg-next-sys = "5.0.3"

Note that libav will be built from source, but it will be cached for subsequent builds of your project.

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

Really? It seems more complicated than that.........

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

Ah, should have been more explicit: you also need a working C compiler (+ make, pkg-config, etc.) and the libav development headers.

As for libav itself, if prebuilt libraries are not present, the build script will fetch the source and build it as a static lib.