What about using Python (with system calls) to build the project? Much more understandable than Makefiles.
There is also Snakemake[1]. I did not decide for myself yet if I prefer it over make.
Makefiles – Best Practices
71–80 of 127 posts
Re: Makefiles – Best Practices
#72I really wish blog posts like this would at least mention that they are going to use GNUMake extensions. There's some good stuff in here, but just calling it "make" and leaving it at that is misleading. It's not going to work on my minimal (non-GNU) Linux boxes that mostly run NetBSD make (bmake in many distros) or busybox style tools. I know a very small minority of people do something like that (or maybe not, what…
I doubt most people even know that there are different versions. (I didn't!)
It's pretty common knowledge that there are differences from the GNU package set and linux package sets.
I've been exposed to this multiple times: from downloading GNU packages using Homebrew on OSX, downloading different packages on Android, the variety of options available to ArchLinux users, etc.
Anyone with basic Linux knowledge should be well aware of this. From a minimum of following tutorials and having the basic command flags not work on common terminal programs.
Re: Makefiles – Best Practices
#73Earlier quoted context omitted.
I haven't found a reason to not just use Make yet when starting from green fields, including some very big projects. In fact, I have often been annoyed at some projects picking something like CMake for no reason beyond it's "more advanced," but which ends up just being an extra dependency I have to fetch and install. If I were to pick one of the above for building large projects on linux variants, which one would you…
For me, I mostly work in embedded Linux - that's Linux for routers, custom hardware, sometimes a Docker image, etc. That means lots of packaging work. Sometimes it means build machines that can't even run the compiled binary. I compile libraries for platforms that the original author would never have imagined. In that space, there are lots and lots of details that need to be "just so". Lots of specifics about the cfl…
Thank you for the detailed response!
Re: Makefiles – Best Practices
#74CFLAGS := ${CFLAGS} CFLAGS += -ansi -std=99 What's the point of the first line? Why not just: CFLAGS += -ansi -std=99
Because CFLAGS may not be set in the environment, resulting in concatenation to an undefined variable error.
There's no such thing as an undefined variable in Make. The variable expands to text. Variables which are not defined by definition expand to no text.
Re: Makefiles – Best Practices
#75Earlier quoted context omitted.
Make is simple.. it gets me started. I can do multiple targets with dependencies and incremental compilation.. Sure, you should be careful of scaling it far. BUT, please enlighten me on a sane high-level build system? cmake, bazel and the like all seems to rely on unintuitive macros. And let's not talk about auto tools :) What other mainstream build system will get you started quickly without unintuitive macros. (I w…
What's more simple than "add_executable(foo bar.cpp)"? It's concise, cross-platform and hides all the boilerplate for you. Sure, everything in CMake is not super intuitive, but I've led workshops were people got the hang of it pretty quickly for simple to advanced cases (including multiple targets and some scripting). Keep it simple, most of the time, you don't need the advanced features at all! Can't say the same fo…
> What's more simple than
CMake 3.6.0 or higher is required. You are running version 3.5.1
Re: Makefiles – Best Practices
#76Earlier quoted context omitted.
> In my mind, the biggest problem is that it offers you virtually no help in writing correct parallel and incremental builds. That’s interesting, because in my mind, parallel and incremental builds are the main features of Make, the features that it is best at, and all other features are secondary. It sounds like your problem is with the correctness part. Make gives you no tools to enforce that your build rules are a…
Yeah I think we're in agreement, except that Ninja is not a replacement for Make. Make is both a high-level and a low-level build tool (i.e. logic/graph description vs. execution) Ninja is only a low-level build tool -- it focuses on execution only, punting logic to a higher level, which I like. See my comments here: https://news.ycombinator.com/item?id=19057836 I used Bazel/Blaze for many years, and even contributed…
> Yeah I think we're in agreement, except that Ninja is not a replacement for Make.
I would definitely disagree with this. Make's higher-level logic/graph description features are only incidental, as Ninja proved, you can remove those features and end up with a tool that is equally valuable, more or less. To abuse an analogy, if I'm shopping for notebooks, I don't need to buy a notebook and pen shrink-wrapped together. I already have plenty of pens.
You're right that Bazel isn't good for open-source projects with diverse dependencies, but I think this is a problem that can be solved by developing some more infrastructure for that and writing the appropriate Starlark code (to be called from your your WORKSPACE file and create the appropriate repositories somehow). That code just isn't around yet.
Re: Makefiles – Best Practices
#77Earlier quoted context omitted.
> In my mind, the biggest problem is that it offers you virtually no help in writing correct parallel and incremental builds. That’s interesting, because in my mind, parallel and incremental builds are the main features of Make, the features that it is best at, and all other features are secondary. It sounds like your problem is with the correctness part. Make gives you no tools to enforce that your build rules are a…
As I recall, the guy who developed Make wrote it in a weekend.
And never expected it to be so successful, and realized that he couldn't fix some of its problems because people were already relying on it.
Re: Makefiles – Best Practices
#78Earlier quoted context omitted.
Yeah I think we're in agreement, except that Ninja is not a replacement for Make. Make is both a high-level and a low-level build tool (i.e. logic/graph description vs. execution) Ninja is only a low-level build tool -- it focuses on execution only, punting logic to a higher level, which I like. See my comments here: https://news.ycombinator.com/item?id=19057836 I used Bazel/Blaze for many years, and even contributed…
> Yeah I think we're in agreement, except that Ninja is not a replacement for Make. I would definitely disagree with this. Make's higher-level logic/graph description features are only incidental, as Ninja proved, you can remove those features and end up with a tool that is equally valuable, more or less. To abuse an analogy, if I'm shopping for notebooks, I don't need to buy a notebook and pen shrink-wrapped togethe…
All I'm saying is that Make was designed to be hand-written and often is, and Ninja was designed to be generated, and almost always is. See the manual:
https://ninja-build.org/manual.html#_philosophical_overview
Concretely, if you look at how Android or buildroot used GNU make, you can't do that with Ninja alone -- you need another tool.
GNU make is Turing complete, and Ninja isn't. IMO the Ninja design is better (which isn't surprising since it's not an accretion over decades).
Re: Makefiles – Best Practices
#79Earlier quoted context omitted.
I've been using invoke [1] which has allowed me to give my projects nice UIs while remaining in the primary language. If I were working on Ruby I would stick with Rake, even though I think invoke is better. [1] http://www.pyinvoke.org/
I really like Invoke / Fabric for Python projects, though it feels weird to use in non-Python projects when it comes to dependencies. [Now I have to explain to non-Python people things like virtual envs, pipenv vs pip vs pipsi, pyenv, etc.] Just curious if you install Invoke individually for each project or keep one global install? I suppose I could always git exclude the tasks.py Invoke files.
I usually keep Invoke globally installed that way I can use it for setting up and interacting with pipenvs externally. Most of my calls beside the initial setup make use of 'pipenv run ' that way I never actually have to navigate inside of the virtualenv for most cases.
Re: Makefiles – Best Practices
#80Earlier quoted context omitted.
OK, 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 bui…
As 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.
Perhaps we need some kind of make8 tool to check for best practices and prevent us writing these magic make files.