The advice in this video is very very bad. You should use setuptools. That is the de-facto standard for Python projects. Imposing your own build toolchains just because you prefer them is very unprofessional behavior, even worse if you are using something just because someone on RUclips said you should. Make is a great tool, I use it constantly on my own simple projects, where I know I will have a consistent build environment etc. But you should always prefer the standard build tools of whatever community you are working in. Python's standard right now is setuptools.
Before I take advice like this from someone on RUclips, I look at how quality developers have done things on open source projects. My go-to for a highly respected set of developers is the go language team. They do not use make, instead they include build scripts for each platform: `all.bat`, `all.bash`, `all.rc` files etc. They do use make in particular spots, like their dist tool, but they don't take the preposterous opinion that it is the only tool that exists or anyone should ever use. Make is only one tool. It is the de-facto standard for Unix utilities and C programming, but other types of projects often have their own build tools. I do personally use Make files on most projects, even when writing blog posts, or typing up slides for a presentation, I fall back to Make because it's an easy tool to fall back on, especially since I'm almost always working within a unix-like environment. I think it's a great tool to use, especially when it's a project you are solo on, or that you are NOT going to share with other people in a different environment. However, it is by no means the end-all and be-all, and if the development community you are working in has their own tooling instead of Make, such as "go" with golang or "npm" with node or "cargo" with Rust, "setuptools" with Python etc. It is perfectly professional to adhere to the standards of that community rather than imposing your own preference for make. Often, adding make to the project can be actively harmful, because you can add anything to a makefile. With no restrictions comes no guarantees. For example, in Python if you use the de-facto standard setuptools, you know your project can easily integrate with other Python projects and standard module distribution methods. Of course, you can layer make on top of that, but you will need on your project confidence of strong developer discipline and training to understand what needs to be delegated to the setup.py file and what can be included in the Makefile. If you use make, you can add any commands at all to it, it has no guaranteed way of ensuring you have a consistent environment etc. It does not provide any of the benefits and guarantees of other build and distribution toolchains. Make solves one problem well: helping C programmers in the Unix programming environment from forgetting to rebuild object files after source code has been changed. That's it. Yes, it's easy to fall back on for automating build processes, but it's not a good habit, and recommending people avoid something like npm or whatever standard build tools exist in their communities, is extremely harmful advice to spread.
Make is cool, but it's also so, so outdated. It's fine to use for small projects but for anything even a bit larger use proper build systems like CMake or Meson, please.
It’s astonishing how much the GNU project put forward that still competes with modern tooling.
make did not originate from the GNU project
GNU ain't great. I prefer git.suckless.org/9base/
Wow! Yesterday I just thought how to add build info to my python project… now I know the answer! Very useful video, thanks a lot!!!
The advice in this video is very very bad. You should use setuptools. That is the de-facto standard for Python projects. Imposing your own build toolchains just because you prefer them is very unprofessional behavior, even worse if you are using something just because someone on RUclips said you should.
Make is a great tool, I use it constantly on my own simple projects, where I know I will have a consistent build environment etc. But you should always prefer the standard build tools of whatever community you are working in. Python's standard right now is setuptools.
I love this. The past never dies; it's not even past
I'm a DevOps and always ignored and avoided makerfiles for some reason, this made me use it
Oh! such a great video to explain WHY i need make. Indeed, it make sense to replace all the online'ish sh files
Before I take advice like this from someone on RUclips, I look at how quality developers have done things on open source projects. My go-to for a highly respected set of developers is the go language team.
They do not use make, instead they include build scripts for each platform: `all.bat`, `all.bash`, `all.rc` files etc. They do use make in particular spots, like their dist tool, but they don't take the preposterous opinion that it is the only tool that exists or anyone should ever use.
Make is only one tool. It is the de-facto standard for Unix utilities and C programming, but other types of projects often have their own build tools.
I do personally use Make files on most projects, even when writing blog posts, or typing up slides for a presentation, I fall back to Make because it's an easy tool to fall back on, especially since I'm almost always working within a unix-like environment. I think it's a great tool to use, especially when it's a project you are solo on, or that you are NOT going to share with other people in a different environment.
However, it is by no means the end-all and be-all, and if the development community you are working in has their own tooling instead of Make, such as "go" with golang or "npm" with node or "cargo" with Rust, "setuptools" with Python etc. It is perfectly professional to adhere to the standards of that community rather than imposing your own preference for make.
Often, adding make to the project can be actively harmful, because you can add anything to a makefile. With no restrictions comes no guarantees. For example, in Python if you use the de-facto standard setuptools, you know your project can easily integrate with other Python projects and standard module distribution methods. Of course, you can layer make on top of that, but you will need on your project confidence of strong developer discipline and training to understand what needs to be delegated to the setup.py file and what can be included in the Makefile.
If you use make, you can add any commands at all to it, it has no guaranteed way of ensuring you have a consistent environment etc. It does not provide any of the benefits and guarantees of other build and distribution toolchains. Make solves one problem well: helping C programmers in the Unix programming environment from forgetting to rebuild object files after source code has been changed. That's it. Yes, it's easy to fall back on for automating build processes, but it's not a good habit, and recommending people avoid something like npm or whatever standard build tools exist in their communities, is extremely harmful advice to spread.
Well said!
Great video. I’ve only ever used make after cloning a new repository. Now I know what it does.
100 % agree. I use Makefiles all the time.
Just one word. Absolutely!
Hi. Are Makefile similar to Jenkinsfile in some way (different languages but same purpose)? A good thing is to mix both 😊
so what was the error with the makefile?
all: test.html should have been on the same line, sorry
A good makefile is fantastic.... But I have seen some dark and terrible things done with make....
did you try asahi linux kai?
Don’t have a spare m1 and I’m happy with my Thinkpad tbh
Make is cool, but it's also so, so outdated. It's fine to use for small projects but for anything even a bit larger use proper build systems like CMake or Meson, please.
Or goredo? ruclips.net/video/2qGyn8RGYxY/видео.html
get to the point....