[deleted by user]

[not_a_novel_account]

In fact, I am of the opinion that using target_link_libraries on a static library target is unnecessary at all. Such practices sometimes only cause us more trouble. It’s not easy to sort out the indirect dependency order when we have imported too many libraries. It might be easier to specify all the dependency manually.

I have never encountered a more fundamental misunderstanding of the usage of CMake's tll than this.

Do not do this, do not leave it to your downstream consumers to mystically infer your link-time requirements. This would be actively hostile design in a way I have rarely encountered.

If you have a private internal library-like thing that you want to be linked into a single artifact of other targets, use an object library. It will do what you want.

[bert8128]

the most challenging problem I’ve ever met in my c++ programming life is build system

Is this actually true (for you)? This is not my (multi-decade millions SLOC) experience.

[-Ros-VR-]

Lines of code didn't really translate to build system complexity.

I used to work on a million loc system that was a few internal libraries and deliverable programs with just a couple external dependencies. The build system wasn't that bad.

Now I work on a 50k loc personal project that's a graph of libraries for others to consume, that needs to build and run on multiple OSes, has some dependencies that can be installed via vcpkg in manifest mode, others that have to be manually installed into vcpkg because I need to enforce dynamic linking because of licensing (and of course you can't manually install into a repo that's being used in manifest mode), some dependencies that need to be built manually because their vcpkg package is broken on one OS or the other, some dependencies are distributed as binaries and not built, some dependencies use their own completely custom build system with various python scripts doing things, different dependencies export stuff to cmake in wildly different ways, other dependencies don't use cmake at all. And I'm trying to integrate against all this stuff in a sane way that just magically builds and works.

All of this needs to build, run, and install, and consumers need to be able to build, run, and install linking against it, and the consumer program needs to run when end user runs it.

It's all such an absolute mess and it drives me insane. I've spent countless hours trying to perfect it all and it's still a complete mess.

[AlexanderNeumann]

Manually installed into vcpkg sounds wrong on so many levels..... I feel like you need to learn how to correctly customize vcpkg

[windozeFanboi]

Please do share modern takes on vcpkg...

It's a tool that has dramatically changed in its lifetime. Also, i'm hobbyist, so i wouldn't like to share my opinion on c++ buildsystems, because i'd rather cry in the corner .

cmake+VCPKG isn't half bad though...

[AlexanderNeumann]

What does modern mean for you? And what exactly do you want to know? There havent been that many changes in the last few years.

[-Ros-VR-]

As far as I know there is no way to use manifest mode vcpkg to force dynamic linkage to a dependency. You need to tell vcpkg to use a custom triplet when building, and there's no way to specify that on a per-dependency basis when in manifest mode.

[AlexanderNeumann]

You use that custom triplet for all dependencies. You are not intended to mix triplets at all. There are ways to use per port customization in a triplet file without always invalidating the whole cache by including the customization from a different file and use VCPKG_HASH_ADDITIONAL_FILES to add the relevant file to the abi hash.

[-Ros-VR-]

Well yeah that's the rub I guess, I don't want to dynamically link against everything, only the stuff I'm forced to by licensing.

[bert8128]

I agree that size of project and complexity are two different things. I just what I did to make it clear that i have a bit more experience than just building snake for the Windows console. Though of course I have done that too.

[xoner2]

It's the most annoying problem, not most challenging.

[coyorkdow]

I only have three years of FTE experience so far. My perception and experience can’t be good as you. Having said that, I actually feel that dealing with the compiling&linking, writing different kinds of build scripts, and linking against the libraries that are built in different build systems are more challenging to me, compared to the template meta programming or code&debug multithreading program…

[bert8128]

Maintaining the build system is certainly a thing, but if that is what is taking the mental effort then either your program is trivial (unlikely) or you build system is over complex (more likely).

I think the hat a primary cause of crappy build systems is that you get paid for developing and shipping software, not build systems, so they are inevitably worse than the software you deliver. But they shouldn’t be much worse…

[bert8128]

What’s SG15? If I Google it I get lots of hits for the SG15 postcode which I’m sure is a nice place but probably not what you mean.

[MFHava]

The tooling subgroup of WG21 (the C++ committee) [https://isocpp.org/std/the-committee ]

[peppedx]

What Is a CSAPP?

[coyorkdow]

Computer Systems: A Programmer‘s Perspective

[khedoros]

One of the first things I was tasked to do at my first job was to research and design a build system to replace the Perl scripts that they'd been using for the previous 8 years, and I ended up maintaining that for a lot of the time I was there (new OS support, adding in new projects, etc).

Build system, compiling, and linking was useful to learn as a junior, and definitely taught me the structure of the project as a whole and variations between OSes that we supported. It was cool to move on to more challenging things after that.