What is the problem?

@@SmokCodeit’s just way too complex. Premake is much easier and simple to understand, learn, and write

@@poopingnuts i think you can't have more control in premake than in cmake i will buy that book and read it surely.

2nd edition is coming mid year!

As software grows in capabilities it grows in complexity and build setups must deal with it. However, if you compress complexity at one end you will make room for more complexity at another end. The cycle is endless, there is no escape from the software samsara. But... for those of us who still want computers, gotta make do with 400 page manuals. That seems like a decent investment in front of endless hours of bestemmie one can get into by using other tools.

Agreed

I'm glad you're enjoying the book! I don't know what book shops have their presence in Belgium, but some of the biggest ones have license to sell books from Packt in their countries. See if you can find any. Another solution might be buying on Belgian Amazon, which works great if you have a friend with Prime who could order the book for you. www.amazon.com.be/dp/1801070059 If all fails - maybe an ebook would be more suitable? Good luck with your C++!

​@@SmokCode That works! Amazon had it too since they're in Belgium now. I just had one more question I didn't see addressed in your book and I'm having difficulties finding an answer for. How do you deal with targets with hundreds of source files you want to logically split up a bit as some components/folders might get extracted later on? A giant CMakeLists seems a bit icky, object libraries didn't seem to be a great solution either because then I need to link my interface library to every single one of those. So I don't really know if there's any other good constructs to make a sort of division within a single target

Within a single target: you can define variables with filenames and add those to sources list. I'd recommend going with libraries though. If there is a logical relationship between files, it creates an opportunity to test them together in integration tests and writing them for smaller scopes is more manageable and quicker to codeloop.

I think you might be misusing the compiler a bit. If you're really including other CPP files, you're treating multiple compilation units as one. This means that a lot of code is being recompiled when it needn't. This approach may work for small projects, but as your codebase grows it slows down exponentially. Consider reading up on SOLID principles, you might be in for a treat!

@@SmokCode I was being general. I work in game development, and depending on project size I either have two compilation units, system and game, or four, system, graphics, audio and game. Here, system is an API layer I've written that connects the game code to the OS and hardware, and this almost never changes. Graphics, audio and game change often, but in small projects I put them into the same compilation unit. In small projects it takes less than a second to compile and link, and in larger projects so far it's always been less than 10 seconds. But even if I did full recompilations, it seems that the linker still takes almost half of the compilation time. SOLID consist of five principles, but I assume you're particularly referring to dependency inversion, since we're talking about project structuring? In game development it's mostly about knowing the hardware you're developing for, and knowing your data. In the cases where I need this kind of decoupling that DIP offers, I can just use a function pointer. Well, I guess that's a form of dependency inversion too. In general, I don't want to use principles that sacrifice runtime efficiency for a benefit that I can get in other ways. EDIT: I forgot to write that many projects I've seen are structured around an object oriented model, and there's a compilation unit for each different class, and there are dozens, maybe even hundreds, or in large projects thousands of classes. I realize that having only one compilation unit per entire subsystem is very different and might seem strange :)

I agree. I'll be sure to forward this comment to the publisher. There's a second edition coming up!

@@SmokCode just came down from my office where I was back to reading this incredibly helpful book.

Same my country, 1 USD is 11.284 UZS for us, what cost is?

Is true tho, i mean 6 bucks for 1 dollar is tooo much

I'm sorry to say that I think that's not an option with Packt. If you find out otherwise please let us know

Some of chapters will. But not all of the book, since I focus on practical use which often means employment of external tools which are often language specific. See the list of chapters and assume that first part works for C, second somewhat works, and third mostly doesn't. If that's enough for you, you'll have a good use of the book. Thanks for your question.

Cześć. W tej chwili nie planuję filmów po polsku.

That's right.

Trochę taki feedback bez konkretu. Nie wiadomo czego dokładnie zabrakło, ani jaki był cel. Książka ma przecież image dockera z pełnym stackiem i można wypróbować wszystko na gotowym.

What do you mean? Compilers are the massive build tools.

@@SmokCode I find it far simpler to say something like "gcc hello.c ..." or "cl hello.c ...". It's not much work. It's usually a line or two. It doesn't require me to then install, maintain, and learn an entire suite of commands and syntax. In other words, things like cmake feel redundant. They are solving a problem, rather poorly, when it has already been solved and isn't very complicated to start with.

Every time you type a command you're redoing the same work you did previously. You may introduce mistakes, and it's not viable to do it on large scale. Even hobby projects often have hundreds of files, and commercial solutions have orders of magnitude more. Keeping track of lengthy commands that change over time is difficult and recompiling everything by default wastes time that quickly adds up.

I should make a video to explain this in detail..

@@SmokCode Yeah imagine typing "gcc ...." to compile a huge and complex project lol. Maybe he is basing his comments on the project you demonstrated on the video, but this is not even close to real scenarios where you need to manage compilations to different targets and manage dependencies for example! Will be nice if you show some real (open source) projects and how they handle their compilation process. I think serenityos uses cmake to generate the build tree, I don't know if you know this project though.

Nope, gave up before the 5 minute mark. Good luck with the book.

maybe, i barely can hear xD

🤢🤢🤮🤮🤮

No problem!