Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Ultimate Frontend Build tool: make

algorithms.rdio.com

Post reply on HN
Print view View original

91–100 of 121 posts

Re: The Ultimate Frontend Build tool: make

#91

Post by lmm »

mathrawka wrote: post #29
badman_ting wrote: post #24

Earlier quoted context omitted.

> When you are learning that new JS framework, do you not keep going through their docs and googling? Yes -- and then I proceed to use the thing every day. I wouldn't be adjusting a Makefile very often so I would keep forgetting whatever I "learned" every time I changed it.

Let's say the JS framework is Grunt. If you are using Grunt everyday, doesn't that mean you are modifying it? Then you would be in the same exact place as with a Makefile.

The point is that the JS syntax of the gruntfile is a syntax I'm using every day. Whereas make's syntax rules are bizarre and used nowhere else (IIRC it makes a distinction between tabs and spaces?)

Re: The Ultimate Frontend Build tool: make

#92

Post by rmrfrmrf »

OK, I get the simplicity of using make, but, yikes, creating your own "little programs" that parse AND EDIT (?!?!) code is a simple solution? IMO the author glossed over that part very smoothly without even bringing up the potential pitfalls (bugs in author's "tiny little programs", invalid html causing the parser to barf, etc etc etc). Really I think you'd have to be pretty stubborn to not see the value of Grunt when you decide that you need to implement an HTML parser as a substitute for if-statements. Lol geeze.

Re: The Ultimate Frontend Build tool: make

#94

Post by matthiasv »

microtonal wrote: post #87
matthiasv wrote: post #73

Earlier quoted context omitted.

> 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.

With a non-standard mess on its own ... 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…

Sure, if you do the packaging for a restricted set of environments yourself, CMake certainly works fine. I do the same for a lot of projects and know what CMake is capable of.

But when it comes to the differences between all those Linux distributions, the respective packager will be very glad to see that he can customize install prefixes (no, CMAKE_INSTALL_PREFIX is not enough) and use standard make targets.

Your list of dependencies shows libraries that are well covered by the stock CMake modules but try getting a build variable that is not LIBS or CFLAGS from a library that can only be queried with pkg-config. Impossible.

Re: The Ultimate Frontend Build tool: make

#95

Post by nicholassmith »

girvo wrote: post #81

Now this is going to sound weird, but I use Make for my PHP development. Seriously. It's perfect, and is installed basically everywhere I could want to run it, and it's super lightweight but just powerful enough. 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 rec…

90% of the time if a project uses CMake I'll look for an alternative as I can count the amount of times I've had hassle free compilation with it on both hands. It's a perfectly fine build system that does handle a lot of weird cases, but I've found reliability wise it's far flakier than standard make.

Re: The Ultimate Frontend Build tool: make

#96

Post by microtonal »

matthiasv wrote: post #94
microtonal wrote: post #87

Earlier quoted context omitted.

With a non-standard mess on its own ... 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…

Sure, if you do the packaging for a restricted set of environments yourself, CMake certainly works fine. I do the same for a lot of projects and know what CMake is capable of. But when it comes to the differences between all those Linux distributions, the respective packager will be very glad to see that he can customize install prefixes (no, CMAKE_INSTALL_PREFIX is not enough) and use standard make targets. Your lis…

But when it comes to the differences between all those Linux distributions,

That's a fair point. However, most often, I am more interested in accommodating the 99.8% of the population that uses Windows, OS X, or one of the major Linux distributions, than the tiny group that runs Sabayon and is able to get things compiled themselves if necessary.

Re: The Ultimate Frontend Build tool: make

#98

Post by criswell »

hunvreus wrote: post #72

I love make too, but still settled for Gulp (and previously Grunt). Writing a Makefile just isn't for the faint of heart and can be very frustrating for front-end folks. It's a trade-off between simplicity and convenience.

I just couldn't get comfortable with grunt, with gulp I had no issues.

Re: The Ultimate Frontend Build tool: make

#99

Post by rwmj »

shadowmint wrote: post #71

The problem with make is not that it's bad, it's that's it's only really good at doing two things: 1) mapping a source pattern to an output pattern 2) managing dependencies between rules To be fair it's good at those, and often the sorts of things you can do with a rule are quite complex (being basically shell scripts). However, the problem is that 1) it's an obscure DSL and 2) that it is really rubbish at doing more…

I'll offer my own input here, goaljobs[1]. (By the way I don't recommend people to use goaljobs unless you're prepared for a lot of assembling and are interested in understanding what it does -- it's not easy to use at all).

You can break down complex tasks like "Has my software been delivered through the app store" down to goals that have to be fulfilled by carrying out (recursively) many layers of rules, like "did it pass human evaluation?".

It's a generalization of make / build systems.

[1] http://people.redhat.com/~rjones/goaljobs/

Post reply on HN