For my cross-platform game development I've moved to CMake, as it takes care of some annoying bits for me. Not a massive fan of it though, and am tempted to go back to Make for my C++ game dev stuff. Any recommendations for it?
The Ultimate Frontend Build tool: make
81–90 of 121 posts
Re: The Ultimate Frontend Build tool: make
#82Earlier quoted context omitted.
And yet most contemporary hipster build systems are all just shiny make reinventions.
Actually, most contemporary hipster build systems are bad reimplementations of make. Yes, make is a PITA, but every other build system is worse.
Are all things made since 1977 hipster?
Re: The Ultimate Frontend Build tool: make
#83It's shit like this, HN. Why you guys make this nonsense end up on the frontpage is honestly beyond me. So this guy re-implemented the most useful grunt tasks in his own language. Grats. You've wasted time instead of using Grunt. Saving time and not re-implementing things was the point all along. Very few people want to write "small programs" to chain together build tasks. They should be readily available, just work,…
So, well, your argument can be reverted: why try to install a big "let's do it all" machinery which depends on the latest versions of very recent tools, while a simple Makefile, which will run everywhere, would do the task?
Re: The Ultimate Frontend Build tool: make
#84Earlier quoted context omitted.
Making small shell scripts and the appearance of the syntax is a matter of taste, I guess. I personally quite enjoy knowing exactly what a script does but the appeal of make to me is that I can use it in non-JS projects, too. I recently had the need to automate batch of converting XCF files to PNG files. Writing and publishing a Grunt module just for that seems a bit over the top, and it would end up a wrapper for a…
You can use Grunt and gulp for any sort of projects, not just ones involving JS.
In my use case, I was using a CLI utility called xcf2png. Writing a wrapper module seems like loads more work than a bash one-liner that calls xcf2png, no?
Re: The Ultimate Frontend Build tool: make
#85Earlier quoted context omitted.
And yet most contemporary hipster build systems are all just shiny make reinventions.
Reinventions that are cross-platform (this actually matters).
Re: The Ultimate Frontend Build tool: make
#86Earlier quoted context omitted.
My preferred hipster build system (CMake) actually leverages make on UNIX platforms and nmake on Windows :). It just replaces the most of the autoconf mess.
> It just replaces the most of the autoconf mess. With a non-standard mess on its own ... CMake is pretty bad at doing things (standard paths, install targets etc.) that the GNU folks solved a long time ago. Yes, the Autotools are a royal PITA but at least a pain that one knows how to deal with.
Creating portable software and then distributing it with a Posix only build system seems wasteful.
Re: The Ultimate Frontend Build tool: make
#87Earlier quoted context omitted.
My preferred hipster build system (CMake) actually leverages make on UNIX platforms and nmake on Windows :). It just replaces the most of the autoconf mess.
> It just replaces the most of the autoconf mess. With a non-standard mess on its own ... CMake is pretty bad at doing things (standard paths, install targets etc.) that the GNU folks solved a long time ago. Yes, the Autotools are a royal PITA but at least a pain that one knows how to deal with.
Perhaps, but not any that I have had problems with.
E.g. an application that we distribute uses Qt, Boost, Berkeley DB XML, libxml2, libxslt, etc. Producing signed application bundles for OS X, MSI installers for Windows, and packages for Ubuntu has been nearly painless. And that's with clang on OS X, Visual C++ on Windows, and gcc on Linux. If it's easy to produce binaries on the three most popular platforms, with three different compilers, I don't see the problem.
We have tried autotools before. But it's a pain on Windows with Visual Studio. Let alone that I can quickly generate a Visual Studio project to do some debugging.
Re: The Ultimate Frontend Build tool: make
#88With the theme of ageism and NIH being brought up a lot lately, I'm glad to see that the neck-bearded unix philosophy (tm) of composition and single purpose are winning over these complicated object oriented frameworks.
Why not drop the "neck-bearded" bit? Evi Nemeth had more Unix chops than 99.86% of the people on HN and no neck beard.
Re: The Ultimate Frontend Build tool: make
#89redo[1] is almost never mentioned in these discussions. Has anyone tried it in anything significant? It looks good and is a djb design. [1] https://github.com/apenwarr/redo
Re: The Ultimate Frontend Build tool: make
#90I'm glad to see the resurgence in make's popularity among front-end developers. It really is a great tool for not just building apps, but generating files that depend on other files in a declarative way. I manage my website with just make, pandoc, and rsync; and I manage my various ssh configurations with make and m4 (ssh config doesn't have an include directive!). A while ago I wrote an article to help out some fron…
It's also very handy for anything you write in LaTeX: add figures etc. as dependencies, make targets that run R or gnuplot to produce the figures in the right format, etc. make is great for a lot of build tasks.