111–120 of 248 posts
Created in 1977, Make has its quirks. But whether you prefer GNU Make or a more recent alternative, consider the benefits of capturing your workflow in a machine-readable format. Like a programming language?
Using make gets quickly really ugly. I wrote many Makefiles in my life and if you have to try to stick to GNU Make. At least it provides some basic functionality. But even that gets nasty quite soon when you need a simple thing like conditions with "and" or "or". If you have to write portable Makefiles ... well fsck. http://www.conifersystems.com/whitepapers/gnu-make/ There were recent discussions about adding GNU Gu…
Any thoughts on CMake for portable Makefile generation. It seems a lot projects use that.
Earlier quoted context omitted.
Indeed, mseebach's answer is really saying that those metrics are irrelevant to him .
No, what I'm really saying is that if you get to cherry-pick the metrics, you can win any debate. Of course there are tradeoffs in anything, and if the expressiveness of your build script is the deal-breaker for your project, by all means use make. On the whole, I will still argue that more modern alternatives provide a better total experience. Also, note that the OP is directed at beginners.
Using make gets quickly really ugly. I wrote many Makefiles in my life and if you have to try to stick to GNU Make. At least it provides some basic functionality. But even that gets nasty quite soon when you need a simple thing like conditions with "and" or "or". If you have to write portable Makefiles ... well fsck. http://www.conifersystems.com/whitepapers/gnu-make/ There were recent discussions about adding GNU Gu…
Personally, I don't want a programming language in my makefiles. Unless working in a very codified environment (Java and Maven, for example), I think it is vital to keep your build system as simple as you can. If I absolutely need nontrivial logic in my makefile, I would much, much rather be forced to call out to a script file (because it encourages not doing that ). And if you insist on parking a programming languag…
I once used gmake to implement a multi-stage Mechanical Turk workflow. It was awful. The syntax sucks. But it worked consistently, and the core logic was only 110 lines of Makefile. It described the files and the data flow between them. Even now, I can read it and understand it with not too much effort. Make is a very simple functional language. It's restartable. If you type 'make -j 2' it becomes parallelizable. For…
I've used Make in a similar context: building documents. Raw simulation results (.log) -> Processed for plotting (.plot) -> Ugly Fig files (.x.fig) -> Pretty Fig files (.fig) -> EPS files (.eps) -> The final document (.pdf). By including the right dependencies in there, you can have individual figures update themselves when the raw data changes, and whole swathes of charts update themselves when the 'fixer' scripts g…
When any of the dependencies of the final output changed, inotifywait noticed and kicked off a "make", and then notified the xpdf instance to refresh itself. xpdf was nice enough to try to stay on the same page when it did this.
Make is a horrible tool, and is extremely hard to learn. I think it should only be used when generated by other build systems.
Earlier quoted context omitted.
I'm fond of not having the number of build systems I'm responsible for maintaining grow in step with the number of programming languages I use in a project.
All build systems I've come across are quite happy to build code in other languages - just like make. The reason I'd recommend the dominant system in each ecosystem is, well, that: It's dominant, thus likely to be better supported for the issue you're likely to face.
What about Java based tools like Ant or Maven?
Xml is an awful language to program in and every ant file grows with the software it builds => ant files that take more than 2 screens are very rarely maintainable.