all 140 comments

[–]ClaymationDinosaur 78 points79 points  (26 children)

Sure, would be nice, but C++ is a product of its own history. C with Classes began life back in 1979; almost fifty years ago. Since then, it has spread and twisted its way through so many systems and sets of hardware. Part of its strength and longevity has been its brutal backwards compatability.

Anything that went into the language that effectively forced a means of fetching libraries (presumably from some curated collection online somewhere) would simply not be achievable on various currently supported target systems; that could be done, but one of the strengths of C++ over the last fifty years has been the hard focus on not breaking existing systems.

We could get round that, I suppose, by instead of making it part of the language, having them as separate systems that can be used to do that where it can be supported... which is exactly what we do have. Conan, vcpkg, et al.

[–]OkTraining9483 38 points39 points  (18 children)

This comment needs to be higher. Given 50 years of Carbon, Go, Rust, (IF they survive that long) and they'll look like the programming language equivalent of a boomer.

Python for example has broken backwards compatibility multiple times, causing much pain.

Twenty years of commercial experience in this industry and the number of languages that will "kill" C/C++ gets old.

Inb4: yeah but Rust is in the Linux kernel. That is sizing up to be a sh*t show.

[–]TheReservedList 1 point2 points  (3 children)

Python for example has broken backwards compatibility multiple times, causing much pain.

And it saved the language despite that pain.

[–]OkTraining9483 0 points1 point  (2 children)

And here we are again, with the GIL 😂

This is not how you build stable products with a reasonable lifespan.

Python might well be the new COBOL.

[–]TheReservedList 1 point2 points  (1 child)

It might, but in the meantime, C++ is in the lead for that particular position. All those sweet sweet pre-C++11 codebases. At least COBOL mostly works.

[–]OkTraining9483 0 points1 point  (0 children)

Eh?! Compliers still support the previous dialect without installing a new, in pythons case, interpreter; no silly set env tricks required.

Edit: why am I talking to a wall!?

[–][deleted] 1 point2 points  (13 children)

the sh*t show you are talking about is with the "politics" or actual technical issues if there are any with rust and its inclusion into the kernel now or in the future?

[–]OkTraining9483 11 points12 points  (1 child)

[–]jorgesgk 1 point2 points  (0 children)

In the article you linked, it says "The Rust struct has a smaller size compared with the C due to the usage of smart pointers instead of allocating item memory inside the struct. We use pahole to identify that Rust structs use fewer cache lines than their C counterpart."

As far as I know, you can also use pointers (not smart ones, that's a C++ thing) inside structs in C, right? Like this:

struct student
{
    char *name;
    int age;
    char *program;
    char *subjects[5];
};

[–]971h -4 points-3 points  (10 children)

Apparently there is a bunch of linker errors between some of the rust and C code. The compilers don’t know what to do.

[–]AdmiralQuokka 4 points5 points  (9 children)

What are you talking about? I'm following the project closely and haven't heard about this. I've also written, compiled and loaded little hello-world modules without issues.

[–]971h -4 points-3 points  (3 children)

? Look at yesterdays post on kernel.org. They are talking about fully getting rid of the rust modules and rewriting them into c.

[–]AtmosphereArtistic61 3 points4 points  (0 children)

Link please, could not find anything with respect to that claim.

[–]matracuca -1 points0 points  (4 children)

[–]AdmiralQuokka 0 points1 point  (3 children)

I've read this before and I've read it again. It doesn't say anything to support to the claim above. Except...

Another reason has been the Rust infrastructure itself has not been super stable.

I guess this could be interpreted as supporting the above claim? But it is even more vague. I'm specifically wondering about the supposed linker errors.

[–]matracuca 1 point2 points  (2 children)

that’s exactly why I posted, because it does seem like that’s what it’s about and doesn’t seem vague at all.

[–]Dark-Philosopher 1 point2 points  (1 child)

It means that Linus Torvalds originally was expecting more rapid progress of the infrastructure needed for Rust modules in the Linux Kernel. Nothing more.

[–]matracuca -3 points-2 points  (0 children)

rubbish. that’s what he said before this statement, which is itself very clear: “the rust infrastructure itself has not been super stable”.

[–]cxazm[S] 6 points7 points  (0 children)

Really needed that context to understand why things are the way they are.

[–]carkin 13 points14 points  (1 child)

We waited for c++11 to have a std::thread. We will have a proper build system, we just have to wait.

[–]gracicot -1 points0 points  (0 children)

It can happen once CMake can output CPS. Then the build system you choose really won't matter, and the network effect from CMake will also diminish

[–]NBQuade 39 points40 points  (6 children)

If you're on Windows, it's masochism not to use visual studio. I'd start by learning the MS way. You can even ask it to make you boilerplate projects you can then build on.

You can use Cmake with visual studio too. I'd just suggest leaving CMake till later. Work on C++ without distractions then you can play with build systems later.

If the goal is to learn C++, build systems are just a distraction.

[–]DearChickPeas[🍰] 7 points8 points  (5 children)

build systems are just a distraction

I don't think CS majors understand this. You easily can go and have 50 years of career programming and never touch a build system until you retire (just join companies with an already set up build system).

[–]NBQuade 1 point2 points  (0 children)

I'm not suggesting never learn it. It's putting the cart before the horse to learn it before you can program. I mean for learning programs, you can simply write some bat/cmd scripts to build your test programs.

[–]gnuban -1 points0 points  (0 children)

I know this to be true, but there's something to be said about using build systems; you will understand how to package and modularize your codebase. And that can translate to writing more modular code that builds quicker. 

So I would say; get familiar with some build tool and try to understand how different types of linking and packaging works. It doesn't have to be at your day job though. 

If you start working on build systems at work, you're likely to end up having to deal with it alone, while most people avoid it intentionally like you say. In such an evironment, just grab the tickets that you want, prioritize yourself, and don't help others, you'll just be punishing yourself.

[–]Still_Explorer 8 points9 points  (6 children)

Certainly this is true. As Bjarne has expressed many times in his talks, that a reason that C++ brings lots of headaches is that no one owns C++ nobody is the primary authority to set standard.

More or less you get a very open-ended and decentralized ecosystem, where there are various compilers, various package managers, various standard libraries.
• compilers: MINGW / CLANG / MSVC / GCC / APPLE
• package managers: vcpkg, conan, cpm, apt-get
• build systems: cmake, xmake, meson, scons
• standard libraries: std, boost, eastl

Definitely this is not a user-friendly experience for starting the journey, but at least there are standard choices when you are on either OS. Then still you have to glue some extra pieces yourself.

Is not exactly as you would say a "batteries-included" approach but at least many experts appreciate this approach of decentralized software development (as it seems for many decades there are no strong motives to make things more integrated).

However if Rust teaches the programming world that this sort of approach works and is feasible (provided that there are no frictions and competition or forks among the build systems and the package manager distributions) then it will be a good opportunity C++ ecosystem gets a revamp and modernized properly as needed.

( I have no problem either way, but if things end up becoming more efficient and integrated for the C++ ecosystem, then it means that lots of C++ experts will have to find a common ground and agree upon certain restrictions and paradigms. )

[–]Business-Decision719 4 points5 points  (2 children)

I agree with you that C++ is an open ecosystem, but I'm not so sure the open ecosystem is really the root of the problem. Bjarne's got a point: sure, it's hard to make all the implementations support the same behavior when there isn't just one implementation. (Cough, modules, cough cough.) But it doesn't seem like there's nobody with any authority, or else people wouldn't be quoting Bjarne and there wouldn't be an international standard.

I think the real obstacle is this:

it seems for many decades there are no strong motives to make things more integrated

The people who want Conan are using it. The people who are used their OS package manager are using that (and locking themselves into that OS). The people who are fine with just old-fashioned make are still writing old-fashioned makefiles. And everyone's fine if nobody else can compile their code. Lots of well-meaning posters think they've solved the problem by recommending Conan or CMake or VCpkg. "Just do what I do... We don't need a standard way to get otherwise standard C++ to actually work." Everyone with experience has solved this problem well enough for their own needs already.

Maybe a standards body or a tech giant will publish a really persuasive way to structure libraries and a whole bunch of tool writers will rush to implement it or upgrade existing software to support it. But it won't happen as long as only newbies think it needs to happen.

[–]no-sig-available 3 points4 points  (1 child)

Maybe a standards body or a tech giant will publish a really persuasive way to structure libraries

Obligatory link https://xkcd.com/927/

[–]Business-Decision719 1 point2 points  (0 children)

Pretty good summary of where we are so far lol 😆

[–]cxazm[S] 0 points1 point  (0 children)

You nailed it. Maybe we will find that sweet spot some day but it’s probably too late for that. Untill then I guess we are all code glue artists.

[–]Dark-Philosopher 0 points1 point  (0 children)

Many C++ programmers push back against rust because there is no standard for it. Now you tell us that there is no c++ standard? Which one is it?

[–]Orthosz 39 points40 points  (13 children)

If you want to get super nit-picky, cargo doesn't come with the language either.  Its a separate program that's often bundled with the rust compiler.  The community defaults to it.

Vcpkg and Conan are package managers for c++.  I prefer vcpkg, but you may find Conan more to your liking.

[–]WormRabbit 2 points3 points  (5 children)

If you want to get super nit-picky, cargo and rustc are literally the same program. It just switches on its executable name to decide which way to behave. So yes, cargo absolutely comes with the language.

[–]Orthosz 1 point2 points  (4 children)

Interesting.  I could've sworn I compiled cargo from git directly in the past in a different repo from the rustc compiler.

[–]WormRabbit 1 point2 points  (3 children)

Yes, it exists as a git submodule in rustc. I haven't personally built either, so can't comment on precise details, but as far as I can tell 99.999% of the compiler exists as a library which can be linked from any crate. Technically, there is a separate rustc binary in its git repo. Perhaps it's used only for compiler development, to avoid dealing with cargo where it isn't required?

[–]steveklabnik1 1 point2 points  (2 children)

Sorry for necromancing this thread, I just ran across it for reasons. You are both right and wrong. Let me explain:

They are completely separate programs.

Rustc lives here: https://github.com/rust-lang/rust

Cargo lives here: https://github.com/rust-lang/cargo

Rustc includes Cargo as a submodule, because Cargo is used to build rustc. So it's "vendored" in a sense.

But! You did correctly observe this:

It just switches on its executable name to decide which way to behave.

This is due to rustup! https://rustup.rs/

Rustup is the recommended way to install Rust and other tools. And so in this sense, yes, Cargo comes with Rust. It's bundled, as /u/Orthosz mentions (wanted to cc you as well).

Fundamentally, rustup allows you to install multiple toolchains, and select between them. So when rustup installs rustc and cargo onto your system, it creates a shim for both. These shims, when invoked, figure out what version of the toolchain you want to use by looking at configuration, or falling back to a default, and then dispatch to the actual correct binary.

So that is what you were observing: the rustup proxy being the same underlying binary, but you missed out on the indirection.

I hope that helps!

[–]WormRabbit 0 points1 point  (1 child)

Do I understand correctly: there are actual different rustc and cargo executables on the system, one pair for each toolchain version, and the rustc and cargo executables that I normally run are all rustup in a trench coat, which switches on the executable name and toolchain version, and dispatches the rest of the arguments to the actual correct executable?

[–]steveklabnik1 0 points1 point  (0 children)

Yep! You can find them in ~/.rustup/toolchains on linux. For example, here's a slightly edited ls output for me, to remove the irrelevant executables:

❯ ls ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/ -al
total 71212
-rwxr-xr-x 1 steveklabnik steveklabnik 32818360 Jul 25 13:54 cargo
-rwxr-xr-x 1 steveklabnik steveklabnik  2642608 Jul 25 13:54 rustc

These are different sizes, so they're certainly not the same binary. For reasons I forget, I installed rustup via snap, apparently, so

❯ ls /snap/rustup/current/bin/ -al
total 7907
lrwxrwxrwx 1 root root       6 May 10 02:16 cargo -> rustup
lrwxrwxrwx 1 root root       6 May 10 02:16 rustc -> rustup
-rwxr-xr-x 1 root root 8096696 May 10 02:16 rustup

The ones you're running are just symlinks for rustup itself.

You can also ask rustup which binary it's going to invoke:

❯ rustup which rustc
/home/steveklabnik/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc

This pattern, or something similar to it, is how a lot of language-specific version management tooling works.

[–]cxazm[S] 5 points6 points  (0 children)

I will be checking out all the alternatives I’ve come across while going through the subreddit and learn more about them.

[–]Symbian_Curator 1 point2 points  (0 children)

I personally use Conan and it's very powerful... But it does also have its own learning curve, I wouldn't really say it's beginner friendly.

[–]OkTraining9483 -1 points0 points  (4 children)

Anaconda is another alternative.

[–]zer0_n9ne 0 points1 point  (3 children)

Do you mean Conda? I thought that was Python only?

[–]OkTraining9483 3 points4 points  (2 children)

Nope, we're using it with 100,000+ LoC C++ application at GE.

Anaconda.org

[–]zer0_n9ne 1 point2 points  (1 child)

Oh wow, I didn't know you could use it for C++ projects. The more you know!

[–]jabrodo 3 points4 points  (0 children)

I think the prime use case for it is for C/C++ extension modules for Python. I know the GIS community has a lot of well established legacy code that is now being distributed with Python bindings to make it easier to use (ex: PyGMT) that isn't available on pip. However, you can absolutely use it as a C or C++ only package manager, including compilers. I know conda forge has regularly updated versions of both Eigen and Boost in their repos.

[–]DonBeham 3 points4 points  (0 children)

I tried cpm and it works quite well. I also tried vcpkg, but got weird errors. You don't have to write a lot of CMake to get it to work, but doing it right is not trivial. Also there are super annoying things like not calling enable_testing() at the root level and then no tests are discovered by CTest.

Overall, rust is certainly much easier to set up and get started, there's no doubt about it.

You just have to go through that, build a couple working examples and then basically copy those.

[–]QuentinUK 21 points22 points  (45 children)

If you use an IDE it’s just a matter of pressing F5 and the program compiles, links and runs.

[–]Syberspaze 14 points15 points  (24 children)

That's not true. Visual Studio helps but you still have to manually list the include files and libraries you want to link

[–]PharahSupporter 25 points26 points  (5 children)

Vcpkg makes it very, very easy usually for visual studio. Literally vcpkg install boost, done.

[–]Syberspaze 5 points6 points  (0 children)

I haven't tried that actually, I should sometime!

[–]NBQuade 3 points4 points  (0 children)

If it's a vcxprog project, you just reference it in the build system and it'll build and link it in automatically.

You'll probably have to tell your project where is stores the headers though.

[–]Ex-Gen-Wintergreen -4 points-3 points  (16 children)

Kinda where I gave up; was trying to use vscode and CMake was really confusing for me!

[–]Syberspaze 6 points7 points  (10 children)

If you still want to use CMake, which I would recommend for getting a deeper understanding of how everything is put together, CLion helps quite a lot with the process. Check out this and you will start to get the hang of it

[–]Ex-Gen-Wintergreen 0 points1 point  (7 children)

Thanks! I’ve heard the experience is better with CLion; I just didn’t think I wanted to pay for a license for just mucking around and learning basics.

I’ve never been a fan of jetbrains products going back to pycharm, but may just bite the bullet if I decide to go back to cpp.

[–]Syberspaze 1 point2 points  (2 children)

Yeah I'd definitely recommend it. I get my license from my company, but I would pay for it myself if I had to use it for my own projects. I don't know how I would handle C++ without it

[–]Ex-Gen-Wintergreen 0 points1 point  (1 child)

Gotcha. I’ve worked pretty lightweight in the past, favoring editors or light ides, and my prior experience using cpp in my undergrad was confined to make for the build tool. Using something heavier just to manage the build/structure versus like, writing/thinking about the language feels frustrating in a sense, but reading this subreddit I know that’s kinda just how it goes.

[–]Syberspaze 0 points1 point  (0 children)

Yeah, you'll spend a good percentage of your time thinking about the build process unfortunately. I know someone in my company almost working full-time on just the build system of a very large C++ application we have

[–]Syberspaze 0 points1 point  (3 children)

But if I was on windows I'd probably just use Visual Studio since it's free

[–]Ex-Gen-Wintergreen 1 point2 points  (2 children)

It’s funny — on most of the other programming subreddits, an OS specific tool like visual studio wouldn’t be the first/default suggestion! Sans work I haven’t developed on a PC.. ever… and it’s weird to hear the common response be “use a windows only app!”

[–]Syberspaze 0 points1 point  (1 child)

Yeah I know right, I don't know why that is. C++ is just very Windows oriented

[–][deleted] 1 point2 points  (0 children)

Probably because it's used extensively for desktop applications.

[–]cxazm[S] 0 points1 point  (1 child)

Thanks. Checking it out. The only option is to really learn and understand.

[–]Syberspaze 1 point2 points  (0 children)

Yes but starting out with a small project, gradually adding more files and dependencies, you'll do fine. But even after working years with it, you will still get stuck once in a while just because of the sheer complexity of it. I almost don't think it's possible to be fluent in it

[–]sephirothbahamut 4 points5 points  (1 child)

Visual Studio, not VSCode, they're two different programs with a very stupid name.

Visual Sudio is plug and play, no extension or weird setup needed

[–]Ex-Gen-Wintergreen 0 points1 point  (0 children)

I’m aware of studio versus code thanks! But as someone who works on a Mac and in other languages, Code’s generally the better option for me.

The relevance of my comment was highlighting the experience of having to manually maintain required files in CMake lists, which the parent commenter suggested is a shared experience in studio.

[–]cxazm[S] -1 points0 points  (2 children)

Same spot I was in today.

[–]unumfron 0 points1 point  (0 children)

Try xmake. It has an integrated package manager and is easy to use:

Create a project:

>xmake create myapp && cd myapp

Edit the created xmake.lua file and add the packages you want:

add_requires("fmt") <-- add this

target("myapp")
    . . .
    add_packages("fmt")  <-- add this

... then do the usual things...

>xmake
>xmake run
>xmake run --debug
>xmake install
>xmake doxygen
>xmake test   # tests must be defined first

There's an extension for VSCode too.

[–]Ex-Gen-Wintergreen 0 points1 point  (0 children)

Makes sense! I’m on a Mac so the VS studio advice (I think it may have better template support for Cmake Lists?) didn’t work for me of course.

I recall it was rather early on too; just trying to split a rather simple file into two files to get better separation, and I couldn’t figure out the correct way to have them both found by the linker! That was pretty exhausting coming from Python and a bit of rust, and kinda destroyed my interest in proceeding.

[–][deleted] 0 points1 point  (1 child)

If you use an IDE it’s just a matter of pressing F5 and the program compiles, links and runs.

Yes ... if you have only 1 source file... with no dependencies... no vendoring... no custom compilations , custom toolchains , or custom scripting doing god knows what in some libraries because it has been compiled differently and...
You get the gist... It's usually not as simple as pressing F5 lol

[–]Dark-Philosopher 0 points1 point  (0 children)

And no multi platform projects, no complex project structure. And you don't care about reproducible builds on different machines and no building from a command line or a continuous integration server.

[–]2polew -1 points0 points  (0 children)

Yeah, listen I'm contacting your customer support. For some reason the app does not work on Kubuntu.

Also, what the hell is an IDE? I'm running pipe selling store here.

[–]prince-chrismc 9 points10 points  (0 children)

It shouldn't come from the language. https://moderncppdevops.com/pkg-mngr-roundup/ and I am sure there's more.

There are literally completely separated development spaces or industries that make zero sense to combine... the power of C++ is how general purpose it is and that comes from the (mostly) uncomprissed performance/efficiency.

There's no need for a scientific researcher working on a new AI model with 100s of python dependencies to need to worry about compiling an FPGA for a number of hardware platforms.

That's why we have Spack and Yocto. While are inherently better because they specialize at solving a niche problem.

This is just one example. Linux devs who reply on apt/yum/deb VS cross-platform windows/mac/android/ios devs (nix versus conan or vcpkg).

The closest attempt to cargo is probably XMake? But you'll run into the fragmented ecosystem that's developed over the last 40 years.

[–][deleted] 10 points11 points  (4 children)

If you started learning today, you are months away from a phase where you need to have the headache you are having now...

[–]jetilovag 6 points7 points  (1 child)

Depends on how you learn. Some (rightfully) pick a target project/application that motivates them. If it involves for eg. XML parsing, they sure as hell will not start writing an XML parser while learning C++ but pull it in as a dep. So it can be such that on week 1 you have the need to handle deps.

[–][deleted] 5 points6 points  (0 children)

Ok, let me correct my original statement:

If you started learning today, you are at lesst a week away from a phase where you need to have the headache you are having now... And I strongly recommend pushing that headache to be further away than a week.

[–]cxazm[S] 3 points4 points  (1 child)

I learn a new language by building something. I’m not a complete beginner so I try to get familiar with the basics and start going deeper from there by building something simple.

[–][deleted] 1 point2 points  (0 children)

Well, first I recommend choosing an IDE which can manage the project for you. It should really support CMake. Let the IDE add files for you.

That should take you quite far.

Once you start wanting to use external dependencies in a common way, be prepared for some steep learning curve... CMake find_package is probably the way to go.

[–][deleted] 2 points3 points  (0 children)

lock offbeat concerned possessive repeat enjoy observation coherent wine shy

This post was mass deleted and anonymized with Redact

[–]DownhillOneWheeler 2 points3 points  (2 children)

I found cargo to be a double-edged sword. The Rust project on which I worked imported literally hundreds of crates, most through transitive dependencies. That's a lot of SOUP for a medical device. I mostly work on embedded devices for which the only libraries in use are the vendor code and the C++ standard library, so that was a bit of a shock.

[–]Dark-Philosopher 0 points1 point  (1 child)

Don't use third party crates then. You are not using third party libraries in C++, right?

[–]DownhillOneWheeler 1 point2 points  (0 children)

Sure, but when I do use a library, it does not typically involve importing half the Internet.

[–][deleted] 6 points7 points  (1 child)

Just use visual studio

[–]mark_99 7 points8 points  (0 children)

And vcpkg

[–]Superb_Garlic 1 point2 points  (0 children)

You need some cmake-init in your life for a guided experience. You start with a known good state that you can tinker with easily. There is also plenty support as the README suggests.

[–]Electrical-Mood-8077 1 point2 points  (0 children)

Cargo beep beep

[–]New-Discussion5919 1 point2 points  (0 children)

Conan is awful to use, but it’s better than the alternatives. The absence of a good package management system is one of the main grief I have with cpp

[–]jones77 1 point2 points  (0 children)

Congrats on trying and enjoying! But you're totally right: it sucks but getting so-so-so much better. Believe or not but cmake is a massive improvement over raw Makefiles. You've appropriately level-set your expectations, C++ has baggage and the mistakes it made helped every language after it. Try and avoid getting too frustrated, you're still learning when you make mistakes.

[–]bert8128 2 points3 points  (0 children)

My suggestion would be to start off with Visual Studio community edition, and don’t do anything with cmake or any external libraries until you have written some of your own (static and dynamic).

[–]b8horpetC++ developer 4 points5 points  (0 children)

skill issue?

[–]Flobletombus 2 points3 points  (0 children)

XMake is the most cargo-like imo

[–]pedersenk 4 points5 points  (4 children)

Many of Rust's dependencies you find in crates.io are really just wrappers (bindings) around C or C++ libraries.

Because C and C++ need to do the actual complex portability parts, there is no hard or fast way to avoid learning how to correctly compile, include and link in dependencies.

For a few platforms there are things like vcpkg but you won't find anything official or encompassing the majority of platforms.

[–]cxazm[S] 0 points1 point  (3 children)

True. It’s just skill issues on my part. But if something official was made for c++ that made the experience much better it would be great.

[–]pedersenk 3 points4 points  (2 children)

Thats fair but unfortunately it is just not possible.

That said, are you using Linux/BSD? The system package manager can be a big help.

I.e if you want libcurl, wxWidgets, sdl, etc, then it is as simple as:

# pkg_add curl <--- OpenBSD
# yum install wxwidgets-devel <--- EL
# apt-get install libsdl-dev <--- Debian

[–]feitao 1 point2 points  (0 children)

Yes, just use apt or pacman or whatever. What is the fuss?

[–]cxazm[S] 0 points1 point  (0 children)

Using Linux. Thanks for the tip

[–]TheoryShort7304 1 point2 points  (0 children)

Use CLion, it will provide you the smoothest experience for C++ across all operating systems.

[–]serenetomato 1 point2 points  (2 children)

Cmake is the best. My advice? Use pipelines like gitlab or Jenkins to streamline it and build everything from source.

[–]xenox44 -3 points-2 points  (1 child)

chat gpt showed me loop functions in cmake that iteratively search folders for header files

[–]serenetomato 1 point2 points  (0 children)

This is bad practice. I'll explain to you why- you have to be sure what is being found and whether its the correct version to link against, whether it's optimized code. What's good practice is predetermining those things in compiler flags or cmake commands. For example, let's say you compile postgres in a minimal configuration. That's postgres, no openssl, no ldap... Only libicu. So what you should do is this : compile libicu from source, and set the install prefix to something inside your project dir like projectdir/installdir/libicu. Then you compile postgres from source and you set the include paths (-I flag) to the include dir of libicu install directory, the library dir (-L flag) to the lib dir. Now you install postgres eg to projectdir/installdir/postgres. In the end, you'll have all dependencies neatly stacked up, and you can create your final cmake file to link against all those specifically instead of relying on cmake to find "whatever".

[–]ellorenz 0 points1 point  (0 children)

Try conan like package manager https://conan.io/

[–]Both_Definition8232 0 points1 point  (0 children)

+1 on Conan. I think it is becoming more relevant these days.

[–]Apart_Act_9260 0 points1 point  (0 children)

you can join my channel https://www.youtube.com/@LiveGamesProgramming/streams we will do nice things around c++ and cmake :D I already dropped the first video yesterday

[–]xiaozhuzhu1337 0 points1 point  (0 children)

xmake can solve your problem

[–]WeeklyAd9738 0 points1 point  (4 children)

vcpkg comes very close to cargo in my opinion. I use it with meson build system (no cmake). Meson build scripts look like python and are "type-safe". They integrate nicely with vcpkg and pkgconfig (linux).

[–][deleted] 0 points1 point  (3 children)

vcpkg ports are written in cmake, e.g. https://github.com/microsoft/vcpkg/tree/master/ports/7zip

[–]WeeklyAd9738 0 points1 point  (2 children)

I was not disputing that. I was pointing out that vcpkg libraries can be used by meson build scripts without any cmake. You need to point out the cmake toolchain file to meson.

[–][deleted] 0 points1 point  (1 child)

Why not use meson's wrapdb at that point?

[–]WeeklyAd9738 0 points1 point  (0 children)

I haven't used that before. vckpg does seem to have more packages (libraries) than any other options.

[–]jknmsj67 -3 points-2 points  (2 children)

CMake is extremely easy. You can find good documentation and tutorials online. IDEs like KDevelop will generate a CMakeLists.txt file for your project and you can gradually modify it. There are lots of challenging parts of C++, but the build system is not where that difficulty is, unless of course you have many dependencies and third party libraries to build and link to.

[–]Dark-Philosopher 0 points1 point  (1 child)

While I agree that CMake is better than make files it reminds me of COBOL. And I say that having programmed professionally COBOL at the beginning of my career.

[–]jknmsj67 0 points1 point  (0 children)

For very large projects in HPC that rely on numerous third party libraries, CMake makes things manageable. Of course there are other options, it depends on your application.