Makefiles: 95% of what you need to know 

Really glad to hear it helped!!!

You're welcome; glad you like it!

Thanks for the suggestions! Keep 'em coming! Within the next 6 months, I do want to make a series of videos about systems tools.

@@nothing6001 can't wait to see them coming

Thanks for the request about target-specific variables! I'm thinking of remaking a series of these, and that is useful!

Glad to hear it!

Great question. When you're testing an application, you might manually specify only the dependencies you need (assuming the application is multiple object files). However, as you want a "compile test" to be part of your tests, I'd simplify in most cases, and just have your test dependent on all of the .o files of the application. In the case that you're testing a library, you want to have a dependency on the .a or .so resulting binary, which will likely compile/link the entire library. You want this complete set of dependencies as you want your test to interact with the library in exactly the same way that a client would. In short, I'd make tests dependent on the closest thing to a final output possible.

Thanks!

Generally it is fine. However, depending on the development environment, the commands to perform the flashing might differ. So it is not uncommon to have a shell/python script to do the flashing, and simply invoke the script from the makefile.

@@nothing6001 Appreciate your guidance, thank you!

Thanks so much for the comment! I'm planning on a series of videos about system tools in the coming months. You've provided me some motivation, so thanks!

I don't know any powershell, unfortunately. But this linuxhint.com/delete-files-in-powershell/ says you can simply `rm -fo names*`. Not sure if it is right, or what limitations it has. Sorry!

@@nothing6001 Damn, thank you so much for the answer, big fan of your videos here. Apparently rm is just an alias of the remove-item cmdlet, and it does indeed have some limitations (dammit windows), so it looks like ill be sticking to wsl instead. Again, thank you so much for the answer and the content you put out, if it wasn't for your passion I wouldn't have grasped the concept of makefiles at all.

Big difference, actually. 1. You're adding a dependency on all header files, which means a change in any of them will require recompiling all C files. What the .d files do is recompile the C files only if their specific headers are modified (i.e. not all C files include all headers). 2. it won't include the headers outside of your path. This might not matter, but does if you use libraries *and* modify those libraries. Likely this is not a big deal for you.

Great question. Generally, you can just change the makefile from using gcc to instead using g++ to compile c++ (or whatever c++ compiler you use). Other than that, I'd expect everything should be the same.

It pulls in the C/C++ dependencies on header files. When you compile the C/C++ with, for example, "-MMD", it will output a dependency file postfix with *.d. It includes rules for which .c files depend on which .h files. The line you ask about simply includes the .d files in the makefile. Long story short: if you modify a .h file used by a .c file, you want to recompile the .c file. This enables make to understand which .h files each .c file depends on!

That was my question as well. Thanks

@@nothing6001 Thanks

A dot means "this current directory".

Nothing fancy, just Ubuntu

simply says "look for this header file in any of the 'include paths'". When gcc compiles a program, you can set up the include paths using the "-I" compiler flag. For example, `gcc -I. file.c` would look in the current directory (see the "." there?) for any header files included with . Another example github.com/gwu-cs-os/evening_os_hour/blob/master/f19/10.2-makefiles/02_simple_makefile/Makefile#L2 and a more complex one github.com/gwu-cs-os/evening_os_hour/blob/master/f19/10.2-makefiles/03_featureful_makefile/Makefile#L10

@@nothing6001 ahhh thank you! got it working!

Thank you so much for the thought out comment!!! I don't know how long you've been programming, but it honestly sounds like you're riding the learning curve up programming, bit by bit. Very little of what we do is natural, and it all takes a concerted effort to learn. You also can't really just learn all of it at once, as there are many conceptual stepping stones to get to many concepts. Even for those going through a well-designed curriculum that walks them through those stepping stones, it is very hard, and takes a lot of time. All of that is to say this: have patience, and cut yourself some slack. It is hard, and takes time, but is all learnable with time and effort. How you break up the C/C++ and header files, and how to you break up the Makefiles is very project specific. For the source files, you kind of want to think of breaking up c/c++ files into logically cohesive units. Think: the functions that "bin" together, should be in the same file. There are few rules around how big files should be, or any of that, but generally keeping the logic within them manageable and all self-related is the goal. We split up Makefiles, practically, pretty rarely. A single, top-level makefile can do quite a bit. I can build files in subdirectories, move them around, create executables, etc... The exception to this is if different parts of your project require vastly different ways of being built. For example a library might be separate from your main application code, might be separate from your testing code, each using different Makefiles. But honestly, I don't see this often. In our OS, we have huge hierarchies of Makefiles and I still don't know if that was the right idea ;-) If you're in the root of your project, and you cant to cause a Makefile in a subdirectly (foo) to the rule "all", you use the following in one of your rules: make -C foo/ all For example, github.com/gwsystems/composite/blob/main/src/Makefile#L20-L21 will execute the Makefile in the "components" directory, and execute the "component" rule. All that said, I'd recommend sticking to a single makefile till it feels like it is being pulled into too many directions. Only then use multiple. I don't know of great resources to learn a lot of this. Because of that, I recommend simply using it in one of your projects. Start out simple, then dive further in when you have to. The make references are complex, and hard to understand. But it often gives you enough information to try some stuff out, and see what sticks. I wish I had better news on this, but build systems are one of those things that most people learn by doing. I don't know if any of this is kinda what you're looking for, but a class I taught a year ago was on system programming. Using UNIX APIs and what-not. Might be useful? Might not. Find links here: gwu-cs-sysprog.github.io/ github.com/gwu-cs-sysprog Best of luck! Make sure to allow yourself the time to learn. We all start off not knowing much, and not being able to dive deep into complex topics (I always learned quite slowly). Before you know it, you'll know enough to start learning quickly. Your rate of learning only increases as you learn more. But to get to the part of that learning curve that feels "good" takes time. Some thoughts on this: www2.seas.gwu.edu/~gparmer/posts/2018-06-22-compounded-self-improvement.html

@@nothing6001 Well, that was a heck of a lot more than I expected, though of course I didn't expect much, given the age of the video. I have been developing and programming for decades really, though apart from 3 years in a Job were my official title was indeed IT developer, though I didn't do much programming, never professionally, for the very simple reason, that I simple cannot handle the excessive, and in my not so humble opinion unnecessary and counter productive, abstraktion. Perhaps it has something to do with my autism, who know, but it is what it is. At any rate, I started out some 25 years ago or so, I even did C++, when when it was still the case that one could actually manage to learn it, before it changed into something utterly unrecognizable, and when that happened, I landed on C, and have never looked back. However, Build Systems have never been foremost among my interest. If it has been warranted, I have used make, simply by copying what others have done. There has never been any doubt in my mind, that were I to attempt to comprehend the subject, I would fail miserably, but now I actually rather need to, if I want to get anything done in regards to my newest project, which is the most complex I have attempted so far, and that is actually saying something. At any rate, I am beyond grateful for your effort, answering my, probably not to easy to comprehend ramblings, and I will delve deeper into your answer, when I get the time, and perhaps post some follow up questions, if you don't mind. I have of course subbed, and hope to see some activity at some point. Thanks again, and best regards.

@@FelixNielsen Yeah, I want to find the time to make a series of videos that are shorter, and cover "levels" of different technologies. Time is always the problem. This video was just a twitch stream for a class, but I think I could do much better if I focused on the content. Regardless, we'll see if I find the time. If you're interested in OS topics, my video series on that topic are better thought out.

@@nothing6001 Sounds good. Should you need some sparing or ideas, I am actually, though it doesn't always seems like it, quite the tool, in a positive way, of course. I myself, have been wanting to do a series for a long time now, focusing not so much on a language, paradigmes, specific tools, etc., but on the very fundamentals, on achieving comprehension, problem solving, alternative "out of the box" thinking, heavily biased by my disgust for the prevalent abstraction of the day, obviously. Pretty much inspired by Charles Petzold and his book "Code: The Hidden Language of Computer Hardware and Software", that I read so many years ago, and was the one book that truly lead me to comprehend the inner working of computers, well, comprehend may be a strong word, but strong fundamentals at least, that I fear has not been prioritized for quite some time, and also, more than anyting, fueled my entusiasm. I would describe it as a children's book, to be honest. Even the most tech illiterate, can understand it, and I dare say that even the most praised and talented programmers/developers, might well learn something. Then again, it has been a very long time ago, so perhaps it is utter crap. All I can say is, that had it not been for that book, I probably wouldn't be able to tell and Iphone from a remote control today. Arg, I'm doing it again. I just cannot sit down in front of a computer, without writing a small novel, my apologies, but my central point remains. Chances are that I will never actually get to that point, but it would please immensely to experience someone else doing so. There was a time where I was very much into exactly that, OS programming. I stil visit osdev.org, once in a blue moon, and should you ever find yourself there, you might want to look up the ancient, though presumably still incoherent, ramblings, of one Zacariaz. I may well watch all you have to offer, though chances are *(NULL&(void*)0)--, that I'll ever convince myself, that starting down that path again, is a good idea, in any way shape or form. Best of luck with it all. I'll be watching.

No fundamental reason. Your suggestion that they should be consistent is correct! There are always improvements to be made to code, and you point out a good place where the current Makefile should be cleaned up.

@@nothing6001 oh OK. I thought I was missing something and that there was a hidden purpose to it. My bad 😅

Yup

Just a casual reference to the hitchhiker's guide to the universe. Funny book.

This is not as interesting as you'd think. It is my username (of course), and I usually choose my username on different computers based on programming language constructs (like the y-combinator that is the theoretical foundation for repetition).

You don't need a rule to build the .c file because it already exists! You only need the rules to compile the source files into the objects. Hope that helps.

I’m not an expert (that’s what I’m here for), in this case doesn’t x.c count as a dependency?

emacs, but everyone should just use what they find comfortable.

github.com/gwu-cs-os/gwu_os_editors/tree/master/emacs I've changed it significantly since as that is a ~20 year old configuration before use-package changed the game. Regardless, hope it is useful!