Makefiles and build scripts aren't magic. Yes, all the building guides would have us believe that they are, but there's a lot more going on. You must have the tools to build (i.e. compilers, interpreters, etc.) The nastiest part is usually the dependencies. You have to make sure that you have all of the necessary pieces of code (libraries) installed on your machine.
This varies from language to language - Python, PHP, JS, Rust, and many other such languages let you install many libraries using a special command. (See the documentation for "installing libraries" and "installing dependencies").
By and away, if you're building from source, you're most likely using C, C++, or some other cousin language thereof. Dependencies there are nastier. Static libraries are the easier ones, but you have to include the header files (.h, .hpp, .hxx) for the library in your compiler, and the static library files (.a on UNIX, .lib on Windows) have to be added to both your compiler and linker. Dynamic libraries (.dll) are similar, but often more complex - look those up.
On UNIX (Linux, Mac) systems, many dependencies are easier to handle, as you can just install them via your package manager. If they're NOT available through your package manager, you'll need to track 'em down yourself
Whatever you're building SHOULD have documentation on what dependencies are needed, where they're expected to be, and so forth. If what you're building doesn't have this written down, think again whether you want that code. (Good projects should always document their build process.)
I took a different approach with my answer, but the x isn't actually magic thing is super generally applicable. It took me a long time to realize that if I was confused about how a dependency worked, I can look at its code and maybe find my answer right there! This doesn't always apply, as somethings are closed source or potentially so convoluted that they might as well be magic, but in my line of work I often find answers right in the code I'm depending on.
Makefiles and build scripts aren't magic. Yes, all the building guides would have us believe that they are, but there's a lot more going on. You must have the tools to build (i.e. compilers, interpreters, etc.) The nastiest part is usually the dependencies. You have to make sure that you have all of the necessary pieces of code (libraries) installed on your machine.
This varies from language to language - Python, PHP, JS, Rust, and many other such languages let you install many libraries using a special command. (See the documentation for "installing libraries" and "installing dependencies").
By and away, if you're building from source, you're most likely using C, C++, or some other cousin language thereof. Dependencies there are nastier. Static libraries are the easier ones, but you have to include the header files (
.h, .hpp,.hxx) for the library in your compiler, and the static library files (.aon UNIX,.libon Windows) have to be added to both your compiler and linker. Dynamic libraries (.dll) are similar, but often more complex - look those up.On UNIX (Linux, Mac) systems, many dependencies are easier to handle, as you can just install them via your package manager. If they're NOT available through your package manager, you'll need to track 'em down yourself
Whatever you're building SHOULD have documentation on what dependencies are needed, where they're expected to be, and so forth. If what you're building doesn't have this written down, think again whether you want that code. (Good projects should always document their build process.)
I took a different approach with my answer, but the x isn't actually magic thing is super generally applicable. It took me a long time to realize that if I was confused about how a dependency worked, I can look at its code and maybe find my answer right there! This doesn't always apply, as somethings are closed source or potentially so convoluted that they might as well be magic, but in my line of work I often find answers right in the code I'm depending on.
Here's a post on reading tests to find answers which touches on this thought.