3 ms·
What about using Python (with system calls) to build the project? Much more understandable than Makefiles.
by brookhaven_dude 8y ago
What about using Python (with system calls) to build the project? Much more understandable than Makefiles.
- dbcurtis 8y agoOK, so I am as much of a hard core Pythonista as you will find. But I don't think it makes any sense to build C projects (or many other languages) with Python instead of makefiles. C programmers know make, the makefile idiom has been evolving for 40+ years. A seasoned C programmer is going to look at an idiomatic makefile and find it much more readable than some rando doing some one-off Python script to control a build. And getting build dependencies resolved correctly so that you can only build what is need is not trivial. What I truly hate is all the IDE's that think they can do a better job than make. This is the curse of the embedded world. Building an embedded project requires calling particular tools, with peculiar flags, and I hate with a passion IDE's that obscure all of that in some crappy XML file that is git-unfriendly. A well-structured makefile is your friend in many ways. make is a powertool. Learn it and your life will be better.
- htfy96 8y agoAs a C developer I have to say there exists no idiomatic makefile - configuring header file dependencies with -MMD/auto rebuild targets affected by FLAGS change already makes your Makefile look like magic. As the project grows, eventually you will need some kind of flexibility that makefile cannot do well. In this case, explicit Python scripts become more useful that a bunch of possibly implicit makefile rules.
- kingosticks 8y agoPerhaps we need some kind of make8 tool to check for best practices and prevent us writing these magic make files.
- self_awareness 8y agoMy experiences with Makefiles are different. I can understand mine up to 3 months after I write them. And if I read someone else's Makefile, it's a binary blob, full of hacks, optimalizations, walkarounds and compatibility quirks between GNU make, BSD make, with sometimes different Makefiles for FreeBSD, Linux, OpenBSD, DOS, and Visual Studio uses its own project file in the win32 directory. It's a mess.
- mruts 8y agoIs this a joke? Why would anyone ever do that? Except if the only language you know (and ever want to know) is python?
- self_awareness 8y agoUsers of SCons (https://scons.org/ https://scons.org/), and Waf (https://waf.io/ https://waf.io/) disagree with your point of view.
- q3k 8y agoIncidentally, I have not ever met a single user of either of those that does not hate working with them.
- self_awareness 8y agoMaybe they're simply not from your social circle?
- kodablah 8y agoDespite the downvotes, it is reasonable to write the project build script/workflow in an easy-to-read, cross-platform language. Makefiles often devolve into shell scripts or use of autotools in very slow and not-cross-platform ways. This becomes more spaghetti as you build dependencies between/across projects. Lately with projects that do several things on build, I include a build.go and ask users to just `go run build.go [command]`. I get many features built in, it's quite maintainable and cross platform, etc. Even if it calls out to other makefiles or build scripts, at least you can centralize it and do different things per OS or whatever.
- lixtra 8y agoThere is also Snakemake[1]. I did not decide for myself yet if I prefer it over make. [1] https://snakemake.readthedocs.io/en/stable/ https://snakemake.readthedocs.io/en/stable/
- kbumsik 8y agoI bet Makefile has far more understandable and needs far much less lines than Python for its purpose. Its declarative syntax and "rules" are just suitable for task runners.
- ridiculous_fish 8y agoThe answer is that Make only rebuilds what is necessary. Duplicating this logic in Python is nontrivial.