Earlier quoted context omitted.
> All dependencies of the .PHONY pseudo-target will be rebuilt unconditionally when encountered. To be clear, they will rebuilt only if they are not already up to date relative to their own dependencies, right?
yes. Phony is only about making sure that 'all' is seen as target, not as file or folder
Make for hipsters
111–120 of 200 posts
Re: Make for hipsters
#112Earlier quoted context omitted.
> Of course it is great when you write a language to also throw in a build tool, but in the end if the build tool re-implements 30% or so of make in a broken way I don't see the point. Well, other build tools sometimes also do a lot more than make ever did. (And in some areas, perhaps less.) Example: Cabal/cabal-install (for Haskell) can automatically fetch all your project's dependencies and automatically compile th…
> Tracking intra-file dependencies for proper recompilation is really difficult to for Scala code without reimplementing a huge chunk of a Scala compiler. tup ( http://gittup.org/tup ) has a really nice way of handling interdependencies. They set up some filesystem magic to figure out which files were read while compiling a certain target, and record these files as dependencies for the target. Another instance of a h…
When I decided I needed a single build system to replace a hodgepodge of stuff, I looked at make because that was apparently the go-to thing.
It took me about 2 minutes to decide that I wanted no part of make. I'd assumed it was basically what Tup is. I'm lucky that I learned about Tup from a thread on this site, because it's made me so happy (especially once the initial pain was over... and yeah, you have to change).
So whenever I see these posts, I make sure that someone is mentioning Tup as a clean alternative.
edit: to be explicit, Tup is obsessed with speed and correctness, and handles incremental builds optimally (see Mike Shal's whitepaper on this). The "price" is that you can't modify files during a build. A file is either "regular" (not touched by build) or "generated" (produced wholly from one build rule). You have to describe the complete DAG up front. Because of all this, Tup will actually remove build targets when they're not needed, which I believe no other build system does. I could never go back.
Re: Make for hipsters
#113Earlier quoted context omitted.
But some languages allow an "#include / import" construct. You'll have to somehow walk all those dependencies and convert them into something Make understands.
Why would that be the responsibility of Make? Of course you need to convert those externally -- with e.g. the C preprocessor for C files...
However, my biggest problem with Make is still that it does not allow for dependencies in the form of variables.
Re: Make for hipsters
#114Earlier quoted context omitted.
The problem is if you want support (even commercial help) you'll need to follow some kind of prevailing trend. If I've got a system with grunt or gulp and I need help, I can probably find a local web developer. I'm not so sure if I can find someone who's an expert in Makefiles at the moment.
You already found at least one. Also try anyone with a degree in computer science. I'd wager it's in most first year courses; it was in 3 of mine. Also you could consult anyone who spends a lot of time working on/programming for Linux and/or in C/C++. And it's really easy, and there's tons of literature on it on the internet. And it has a manpage.
Re: Make for hipsters
#115Earlier quoted context omitted.
Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.
> Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Some stuff is genuinely awful. - Sendmail was ubiquitous, but it was, according to anyone who'd had either fleeting or deep experience with it, a beardy wilderness of byzantine hacks and to…
No, really. The "UNIX way" is not just "Use tons of small things to do a simple task, complexity of managing them be damned".
It is indeed "do one thing and do it well", but that "thing" is usually high level enough and ready to go -- not something you need a whole stack of dependencies, configuration, and lots of extra glue to use.
And of course those unix tools should be standard and evergreen -- not like npm module du jour that gets abandoned 2-3 years later or completely rewritten.
Re: Make for hipsters
#116Earlier quoted context omitted.
(1) I imagine quite a lot of this site's visitors use different platforms/toolchains, and haven't encountered make. (2) Its a fun/joke title, the article is for "hipsters", the kind who know the latest fancy build tools but not make, I suppose. I wouldn't take it too seriously. (3) It's a disclaimer against people attacking him for errors, and also to warn people that he's not an expert. Again, this is written in a l…
If not a ruse, this is a dumb post that discredits itself and calls makefiles hacky, not noticing that they are used by many people for most native programming on most (unix type) platforms. I'm feeling cranky every day, but just today this post is at the top of hacker news, and that's frustrating.
Bah, you just take things too literally, and can't process/appreciate some obvious and light-hearted cultural signs.
A post that makes a joke comment != a post that discredits itself.
A post that warns that its own makefiles might be hacky != a post that calls makefiles inherently hacky (in fact this is obvious, since the post's goal is the inverse: to promote Make to people).
A post that tries to introduce Make to a whole bunch of devs who don't know about it != a post that doesn't notice that Make is used by many people for native programming on unices
Re: Make for hipsters
#117Earlier quoted context omitted.
No need to explicitly declare dependencies, you have wildcards and macros at hand to manage redundancy (1). If the compiler/program accepts a file and produces another, it can be used just as easily as the C compiler. My website uses awk, m4 and html-tidy on a pipeline to produce HTML, and with 45 lines of make (with about 10-15% whitespace) I build everything, with html-tidy being optional.
But some languages allow an "#include / import" construct. You'll have to somehow walk all those dependencies and convert them into something Make understands.
a.o: a.c a.h
cc -o ${.TARGET} ${.ALLSRC:M*.c}
This is bmake though, I don't know the posix way because I always confuse $*, $>, $+ etc. There is also mkdep(1), tho I didn't ever use it.Re: Make for hipsters
#118Re: Make for hipsters
#119Earlier quoted context omitted.
yes. Phony is only about making sure that 'all' is seen as target, not as file or folder
This is only an issue if you do indeed have files or folders named the same as targets, right? For example, if you do have an "all" file, you want make to ignore the file when considering the 'all' target, you'd apply .PHONY to the 'all' target.
Re: Make for hipsters
#120Earlier quoted context omitted.
Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.
> Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. Some stuff is genuinely awful. - Sendmail was ubiquitous, but it was, according to anyone who'd had either fleeting or deep experience with it, a beardy wilderness of byzantine hacks and to…
> - SysVinit sucked too, regardless of which replacement you prefer. > - RPM's macro-based .spec file format? Awful.
These are opinions, which is valid.
If you want to have some fun. install centos7 in a vm. Run yum update systemd. Reboot. Your vm is now bricked.
Rpm spec files can be annoying, but what is more annoying to me is the spec behavior changing between rhel/centos 5, 6 and 7.