Thanks, very helpful. I'm new to this area and have been concentrating on learning CMake, but want to know more about how the (non-meta) build systems work as well. Looking forward to other comparisons.
They always say one needs to see something worse to start to appreciate what they have. Make seems really difficult and cryptic. Can you please make a video and talk about what generator expressions are and if we can use them for both single generator systems and multi-generator systems as well?
I can consider making a video about generator expressions. They can be used for both single and multi-config generators. I don't particularly like generator expressions, because they're harder to reason about than the basic build script. They don't work with if/else, because the value in the generator only exists at generation time.
@@KeaSigmaDelta I can totally understand that, but it does seem like they work better for environments such as Visual Studio and others that are multi-config and I have no choice but to learn about them. Really frustrating.
cmake looks less complcated than makefile, but as I use amigaos4 to buildmy little amigaos4 stuff I'm used to makefile, but maybe for laarge projects it can be a PITA.
Sadly, AmigaOS 4's CMake port is rather old, so it's not usable for newer CMake scripts. GNU Make is more complicated, but once you've got a good template, then you can usually get it up and running relatively quickly. I have no trouble using it for large projects, because adding an extra source file to an existing makefile is very easy.
When I tried to compile the code, I got this error .... "Error LNK2019 unresolved external symbol DrawTextureTiled referenced in function "public: class raylib::Texture & __cdecl raylib::Texture::DrawTiled(struct Rectangle,struct Rectangle,struct Vector2,float,float,class raylib::Color)" (?DrawTiled@Texture@raylib@@QEAAAEAV12@URectangle@@0UVector2@@MMVColor@2@@Z) C:\ Src Code\out\build\x64-Debug\ Src Code C:\ Src Code\out\build\x64-Debug\TileMap2D.cpp.obj 1" What can I do to fix this?
I just tried building from scratch using the files I uploaded to the website, and it worked just fine. How are you trying to build it? Using CMake as per the ReadMe? Or did you try to create your own Visual Studio project? If it's the latter, then you need to link to RayLib 4.5.0. The CMake build script will download and build RayLib automatically.
@@KeaSigmaDelta I made it as my own visual studio project, using cmake. I had to comment out several functions from files in the third party folder without knowing why. Well now I know why, I downgraded to an older version of Raylib that didn't have the comments Raylib-cpp needed. I'll let you know if this works as soon as I can
Hello. I'm having trouble with RayGui. When making buttons, it complains about the "{" Symbol right after (Rectangle). Do you know why this is happening? Virtual Studio says "a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax." The code is identical to the one in the download for this video.
Those kind of initializers are a more recent C/C++ feature. Try telling your compiler to use the C++11 or C++17 standard. If you're using C instead of C++, then use the C99 standard. Here's how you do it in Visual Studio: learn.microsoft.com/en-us/cpp/overview/install-c17-support?view=msvc-170
You can use it on multiple platforms, including Windows. However, it's normally only used with GCC. I personally wouldn't use GNU Make with anything other than GCC.
@@KeaSigmaDelta We used it in 94 at a company that had 16 flavors of UNIX. You make is sound like nobody did it. I think that is wrong. I know you have to say stuff to make a point and sell cmake.
@@wjrasmussen666 At no point did I suggest that nobody did it. I've personally used GNU Make on multiple platforms, including Windows. You're welcome to disagree with me. But, insinuating that I'm saying "stuff to make a point and sell cmake" is both overly cynical and rather insulting.
Great video! One aspect of CMake that I find challenging is the `find_package()` command. While it seems convenient at first glance, it often presents several frustrating issues. A common problem I encounter is when I install or download a third-party library and place it in a non-standard location. Each library tends to have its own method for handling this situation, sometimes requiring manual configuration of custom variables for the new location. I'm curious if there's a simpler or more universal approach to address this, perhaps through a single variable that can manage it all.
I personally prefer to either include dependencies directly in the repository, or use FetchContent (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-_5wbp_bD5HA.html). FetchContent will download and build a dependency if it isn't installed. Another alternative are package managers like vcpkg & conan. I don't use those myself (yet more external dependencies including package repositories).
The killer feature of build systems - dependency management, not incremental builds. Which files to build ,where to find internal/external dependencies, what order those dependencies should compile and how to pass those to linker and so on. Incremental builds could work just by using things like ccache and it's not necessary part of the build systems by itself. Also there's at least 4 kinds of compile times optimizations there are includnig caching, parallel building (multiple machine compile different parts of the project), multicore building and smashing files together into big ones. And of course they can be done all at the same time to a certain degree, since each of it introduce it's own quirks to the build system.
Very few C/C++ build systems have dependency management... Of course build systems have more features than mentioned in the video, but if you throw all of them at a beginner then they'll get overwhelmed.
@@KeaSigmaDelta okay, whats dependency management is then? except for resolving system search paths to shove into compiler/linker options and installing them from some kind of registry, what else it is?
@@DeathSugar Let's use the Rust language's dependency manager as an example. It's called "cargo." You tell it what external packages/libraries you need, and it'll fetch them from the internet and install them for you. It'll also install dependencies to those dependencies.
I wrote a simple build system in C++ with compile-time configuration In the build system library, there is simply a function that recursively compiles the files in a given directory into 1 executable file, and this is enough for me, the result is a simple configuration file and the compilation starts as quickly as possible Multiprocessor compilation is present
I personally don't get why people like to set a variable for source files. I'd just list them in the add_executable or add_library call directly, or better, use target_sources. That way you can enable modern C++ features like modules fairly easily and use generator expressions for any platform specific files. If the build becomes complicated enough to justify the variable and it cant be simplified, ok, introduce some variables, but I don't think they add any value as a default.
Part of it's probably habit, which started with older build systems. I do think the script looks cleaner when setting a variable for source-files, though. Plus it's easier to switch when you do get to the point that it becomes necessary.
Making incremental builds using a shell script is actually quite easy. I just think that many people don't always want to put in the effort of learning shell scripting, thus the invention of fancy build systems.
You certainly could try to use your preferred compiler on all platforms if you want. Do bear in mind that each platform has its preferred and best supported compiler toolchain, and using one of the others may come with issues. For example, I do use GCC on Windows, but have run into issues (e.g., certain APIs that aren't supported yet).
What stoppes me from checking if file changed in the script (for example using git hooks, hashing or timestamps) and then build only that .o, then link .exe file? If so, what's the caveats? Sorry if the question is stupid, only started to learn build systems and shell, and want to understand it's advantages and disadvantages.
Comparing timestamps is basically how it's done. However, checking the timestamp of the source-file is *NOT* enough. You need to check if any of the source file's dependencies have changed too. So, you check the header files that it includes, then check the header files that those header files include, and again and again... You're better off using a build tool that already does the change detection rather than try to recreate it on your own.
@@KeaSigmaDelta Oh, so this is basically how makefile works? Plus dependancies and flags of course. Thanks, it really helps to understand makefile workflow better!
@@cycleoffire2220 Yes, although with makefiles you need to add some special code to get the dependency change tracking to work. I cover that in this video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-_DOdoAJf17k.html (and will do so again in a future cmake vs make video)
I’m really confused with what tools to use and how, I’m using Lua and Luau for automation but I can’t seem to figure out how to use FFI I also want to learn low level language like C/C++, Rust and Zig but it is really overwhelming
Lua FFI is only of interest if you already have C code to call. You've listed a lot of different things. I suggest you pick one, and focus on that for now. My CMake Tutorial (cmaketutorial.com/) can help with compiling C/C++ code, but I don't have a beginners C/C++ tutorial (yet). Most people seem to recommend www.learncpp.com/. The Rust language has some good tutorials out there. I've heard about Zig, but have zero experience with it.
To aid you a bit, you shouldn't be aiming to learn languages, but programming concepts and c++ will help you with that, with c++ you could grasp most of the concepts in C & most other high level languages (Java, Python) and the rest, the underlying concepts are basically all the same, Difference is in C, you mostly have to work with algorithms, and higher level languages (APIs and framework's)
Don't freak out or see it as something so tedious or cumbersome, and don't also waste time trying to understand all the concepts, if you don't understand something move past it, as time goes on you'll get it for sure, might be years but you'll understand it. I understand some concepts 3 years later and still understanding concepts till date, most top programmers don't understand all the concepts..
@@chigoziethankgod9579 thank you for the advice, I have been programming with lua for almost 8 years, I’m struggling to find a job that’s why i need to learn other languages
It's refreshing to hear someone say they like CMake because some love to hate it. I found autoconf to be a nightmare, but got pretty good at using make.
that's exactly what I was searching for! Learning C is rather simple, but when I started to search for compilers and build systems, I starting to get lost 🙈 Thank you for the explanation, and eager to watch the following videos 👍
Some build systems are very extensible, so I doubt you'd ever get to that point. If you do, my recommendation would be to stop, and take some time to think about what you're doing and why. Are you making things more complicated than needed?
@@KeaSigmaDelta Well my current need is include modules(not c++ modules), libraries, etc into the build system, if they are needed by project. Only this might not make all the sense in the world, but I also want to know if a module is enabled or not so I can take different code paths (for example: "#if MODULE_XYZ_PRESENT") And my current approach is kinda extending CMake not a standalone build system. So I generate a CMake script at the end with all the required includes and defines
I personally go for simplicity. So, I err strongly on the convention over configuration side. I want building my code to be easy too, not just the end program. This means minimal options/configurations. When adding more options I ask the question: "is the benefit of this feature/option worth the added complexity and future maintenance?"
i think the better solution could be to have build scripts in the project's main language, with *maybe* an (ideally small and uncomplicated one file) library to help implement incremental compilation where it's necessary that way everyone working on the project will already be proficient at the language they use to compile it, and at worst they'll have to learn how a small library works granted this only works if you keep the library small, as soon as you try to add a ton of unnecessary features to make it easier you completely ruin the whole idea of being easy to learn
That's chicken egg problem. You need to compile that file to get your build details, unless you use some kinda weird cpp interpreter. Also that means build scripts can access everything and do everything which might be bad for security
@@paradox8425 i mean, you don't really need to have to have a complex build tool to compile a single file and run it, just a compiler plus it's not really any more unsafe than like, a makefile
@@fiona9891 It's usually not a single file tho. You use one for tests, one for each dependency, etc I mean you can run any arbitrary code in a cpp file. Literally anything
@@paradox8425 yeah, but makefiles (and other common build systems) can execute programs on your computer, which means it can do basically anything a c program can like, theoretically you could make a makefile that writes a c program and compiles it then runs it, so i don't think it's necessarily any more unsafe plus, you can have your main build script build the other files once you execute it, so i think it can potentially still work in that situation (i'm not sure how unwieldy that would be, it's hard to say without seeing it in action, but i'm hoping it shouldn't be too bad and i think using the same language to build your project is a pretty massive benefit) it also means you don't really have to worry about someone having a different version of a build tool because the entire build tool is right there in your project, which you have to agree is pretty great
These standards for build systems suck! I better add a new “better” standard to fix all the issues of the previous ones! /s (this is how we ended up here)
It's funny that I've compiled so much code over the last decade, but I've never heard anyone break this concept down and state it so simply. Wish I had this video when I was confused and getting started! I AM going build another build system though. Sorry about that.
I wish I had a video like this when I got started. As for your upcoming build system. I both wish you wouldn't, and wish you all the best. Maybe your one will finally be the one "that doesn't suck."
I can't speak for any game studio. Nevertheless, a few possible reasons: - Most game studios don't write their own graphics engine, but use an existing one (e.g., Unity , Unreal Engine). Realistically, they can only support platforms that their chosen engine supports - Even if the game engine supports Linux, will there be enough gamers using Linux who would buy their game to justify the expense of porting?
Im a Beginner,only able to write simple terminal applications but your content is simply amazing and easy to follow,i am grateful to have found your channel,wish you sucess buddy
I've been a software developer for 20+ years, and have read about but never really programmed in C++, but I have continuously read about it and its many changes over the years, and finally decided to get serious about picking up C++ because of all the things which you just can't do (well) in other languages-- things like GPU programming for non-graphics apps. Everybody talks about C++ as being full of foot-guns, but I see the language side as being manageable; the hardest part in getting started has been coming to grips with the build system (CMake), IDE integration, and most especially dependency management, and the lack of any any standard. Other popular modern languages either have a standard, or provide tooling for building and dependency management. Anyways, enough with the rant: your example of including raylib with CMake, was the first example that actually worked for me, and I'm including examples from textbooks. I immediately subscribed and purchased your CMake ebook, and am going through your other content also.
Small note. I would not speak in terms of "Visual Studio", which is the mostly name of the IDE, but the compiler name is actually specifically Visual C++, even though it can build both C and C++ code. Hence the abbreviation MSVC.
Thanks for the suggestion. Yes, Visual Studio is the name of the whole package, including the IDE, the compilers, etc.. While MSVC may be more precise, "Visual Studio" is more beginner friendly. People are more likely to have heard of "Visual Studio" than "Visual C++" or "MSVC."
Hey, I see you answer questions in comments so I have to ask too. Let’s say there are assets that have to be packaged together with the binary. How would you install them with CMake, and how would you access these assets (relative/absolute paths) from the binary?
I use a custom post-build command that adds a symbolic link to the data directory from the directory containing the compiled executable: # Create a symbolic link to the data directory after the project is built add_custom_command( TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_SOURCE_DIR}/Data/ $<TARGET_FILE_DIR:${PROJECT_NAME}>/Data/) You can do a similar thing for installing, except you'd probably want to copy the data files instead of creating a symbolic link.
@@KeaSigmaDelta thanks for the answer! Though I’ve met some problems myself with similar method. When you start your binary not from the source directory, but rather from the parent or some other directory (running from terminal for example), the assets are then discovered not from directory of the binary, but rather from directory where you run it in terminal. I’ve solved this by prepending argv[0] to the paths of assets. Maybe, I thought, there is more of an elegant solution.
@@kirillarionov123456 That's because your program is using the Current Working Directory (CWD) instead of checking what the program's actual directory is. Everything is fine when those two are the same, but it fails the moment those are different. You can get the program's actual path from argv[0]. From there you can get the program directory by chopping off the program's filename. After that, you want to convert it to an absolute path (because the CWD can change), and open all data files relative to that. NOTE: argv[0] may point to a symbolic link, in which case you'll want to follow that link to the program's actual directory.
@@happygofishing You can actually use Make on Windows with the GCC compiler. Theoretically, you could even use it with the Visual C++ compiler. However, Visual Studio's command line parameters are completely different to GCC's, so you'd have to supply parameters on a per-compiler basis.
I loved the video, very simple and straightforward, no shenanigans of extra info and I like that I would be interested in a similar style video explaining the compilation process from having a source file to an actual binary executable (or library), with all the magic of linkers and preprocessing in between and maybe a video about how compiled binaries are laid in memory? (This stems from me reading about the -fpic flag) Great video, keep up the amazing content!
Thanks. I sort of go through the compilation process in the video about toolchains: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-9vw0iO6uwUk.html AFAIK, the layout of a program in memory is platform dependent (i.e,. different OSes organize things differently).
I love this channel, it's very helpful for me. I'm using CMake with CLion and MSVC compiler (best support for a new features, like C++ named modules, I was using clang before)
