Is it though? I've recently written on Reddit about how frustrated I am with the fact that a massive amout of young developers don't really understand what make is for. I am probably just a crazy...
(…) Unfortunately keeping your dependencies specified in your build
configuration is time consuming and error-prone.
Is it though? I've recently
written
on Reddit about how frustrated I am with the fact that a
massive amout of young developers don't really understand what
make is for.
I am probably just a crazy whiny irrelevant tech-reductionist at this
point, because the world where you use your OS's kernel's tracing
facilities to “calculate” your dependencies instead of actually
reading your own code seems like the Clown World to me.
Make is nice, but it’s rather annoying that the syntax is shell-like, but actually different in several ways that matter a lot. I’m not a software engineer, but I work with software engineers and...
Make is nice, but it’s rather annoying that the syntax is shell-like, but actually different in several ways that matter a lot. I’m not a software engineer, but I work with software engineers and a lot of what makes them good at what they do is having the discipline to write good Makefiles (or pom.xml files in the case of Maven projects).
It's a trade-off: I'd fancy a Make with better syntax (bmake is better with ${.TARGET}, ${.ALLSRC}, etc., but still POSIX-compliant Make flavour), but the value of it being so wide-spread and...
It's a trade-off: I'd fancy a Make with better syntax (bmake is better with ${.TARGET}, ${.ALLSRC}, etc., but still POSIX-compliant Make flavour), but the value of it being so wide-spread and programming-language agnostic is so great that it's worth learning the few idiosyncracies like how $(XX) and $XX or = and := etc. are different.
(You probably already know all that, but I've decided to write this comment anyway for the readers who don't.) Re. idiosyncrasies: if we're talking POSIX make, $(XX) or ${XX} expand to the value...
(You probably already know all that, but I've decided to write this
comment anyway for the readers who don't.)
Re. idiosyncrasies: if we're talking POSIX make, $(XX) or
${XX} expand to the value of the macro named “XX”, while
$XX produces the expansion of the macro named “X” followed
by a literal “X”. And there is no := operator for macro
expansion at declaration time in POSIX make; it's = all the
way down.
Like anything else in software development, it's always possible to make mistakes, and at large scale it's inevitable. Comparing strace to the dependencies you expected seems like a good way to...
Like anything else in software development, it's always possible to make mistakes, and at large scale it's inevitable. Comparing strace to the dependencies you expected seems like a good way to find errors?
It is a way to find them, but I would say that visualising the dependencies in your ./makefile dependencies with e.g. Graphviz is a much better and quicker one. While we're here, fun POSIX fact:...
It is a way to find them, but I would say that visualising the
dependencies in your ./makefile dependencies with e.g.
Graphviz is a much better and quicker one.
While we're here, fun POSIX fact: ./makefile with a
lowercase “m” actually takes precedence over ./Makefile
with an uppercase “M”. So the only reason why you would want a
./Makefile and not a ./makefile is to “be
consistent with the guidelines of the community or the company”.
By default, the following files shall be tried in sequence:
./makefile and ./Makefile. If neither ./makefile or
./Makefile are found, other implementation-defined files may also
be tried. (…)
Is it though? I've recently written on Reddit about how frustrated I am with the fact that a massive amout of young developers don't really understand what
makeis for.I am probably just a crazy whiny irrelevant tech-reductionist at this point, because the world where you use your OS's kernel's tracing facilities to “calculate” your dependencies instead of actually reading your own code seems like the Clown World to me.
Make is nice, but it’s rather annoying that the syntax is shell-like, but actually different in several ways that matter a lot. I’m not a software engineer, but I work with software engineers and a lot of what makes them good at what they do is having the discipline to write good Makefiles (or pom.xml files in the case of Maven projects).
It's a trade-off: I'd fancy a Make with better syntax (bmake is better with
${.TARGET},${.ALLSRC}, etc., but still POSIX-compliant Make flavour), but the value of it being so wide-spread and programming-language agnostic is so great that it's worth learning the few idiosyncracies like how$(XX)and$XXor=and:=etc. are different.(You probably already know all that, but I've decided to write this comment anyway for the readers who don't.)
Re. idiosyncrasies: if we're talking POSIX make,
$(XX)or${XX}expand to the value of the macro named “XX”, while$XXproduces the expansion of the macro named “X” followed by a literal “X”. And there is no:=operator for macro expansion at declaration time in POSIX make; it's=all the way down.Like anything else in software development, it's always possible to make mistakes, and at large scale it's inevitable. Comparing strace to the dependencies you expected seems like a good way to find errors?
It is a way to find them, but I would say that visualising the dependencies in your
./makefiledependencies with e.g. Graphviz is a much better and quicker one.While we're here, fun POSIX fact:
./makefilewith a lowercase “m” actually takes precedence over./Makefilewith an uppercase “M”. So the only reason why you would want a./Makefileand not a./makefileis to “be consistent with the guidelines of the community or the company”.Source: