351–360 of 525 posts
Earlier quoted context omitted.
C is used in a lot of platforms. Js only in the browser (thankfully mostly converged) and in node.
JavaScript is in the server, browser, mobile apps, desktop apps and embedded devices. Basically, it’s used everywhere that C is used and then some.
More than C? Ha! The platform where your js is running is probably written in C!
I think the reason make is both so controversial and also long-lived is that despite how everyone thinks of it, it isn't really a build tool. It actually doesn't know anything at all about how to build C, C++, or any other kind of code. (I know this is obvious to those of us that know make, but I often get the impression that a lot of people think of make as gradle or maven for C, which it really isn't.) It's really…
Earlier quoted context omitted.
C is used in a lot of platforms. Js only in the browser (thankfully mostly converged) and in node.
JavaScript is in the server, browser, mobile apps, desktop apps and embedded devices. Basically, it’s used everywhere that C is used and then some.
It's the other way around. Every JavaScript program is run by a C/C++ program.
Earlier quoted context omitted.
Your tools support filenames with tabs? With any unicode char? A real world possibility.
Every project I develop is unit tested with strings containing invalid unicode text, containing null bytes, and other random stuff. If a user can’t paste any byte sequence, and expect it to work, then the tool is broken. I handle these cases.
When writing a shell script or makefile to deal with repetitive tasks if is easier to assume some things.
Earlier quoted context omitted.
I don't use CMake for embedded systems because the syntax and options are even more obtuse for what I need to do with it. When I get down to it, every make-based build system I've ever used boils down to using the macro language to generate all the targets, and then building your output board image by dependencies. But it's the details of how to do this that vary widely depending on your application for the board. CM…
It sounds like you are looking for something like Yocto/OE, which you can bake pretty much any build script into, cross compile and deploy. What exactly are you looking for with regards to deployment, and what tool do use, instead of CMake, to give you that ability?
The point I'm trying to make is that every build system except Make solves a really specific class of build problem(building applications, or building Linux systems using GCC) and then pretentiously claims to support everything that matters. What you're actually getting is a small sliver of what you might need in my world.
This article is another example of how Make can do something really unexpected by providing really simple features and letting you decide what matters to you. I've yet to see another build system that is as generally useful.
Thank you. It's nice to know that I'm not alone in this dark, dark world. It's so depressing when people use arguments like "it's old", "it uses tabs", and "it's hard to learn". As described by one Peter Miller, "Make is an expert system". If a tool is the most powerful, standard, and expressive among its peers, its age or the fact that it uses tabs should be inconsequential. If anything, the fact that it's decades o…
> If anything, the fact that it's decades old and used in every major software project is a testament to its effectiveness, not a drawback. Part of the reason is because people see the superficial issues (like the discussion regarding spaces) before they see the value of years (or decades) of work. It doesn't help that when folks bring this up many times you get "you're holding it wrong" type responses. I sympathise…
My issue is that people who need serious solutions forgo Make because "tabs, man", or because Webpack has pretty console output.
I have used make for years and am very familiar with it. My two major complaints are: 1. The assumptions that it makes. Everything in and out are files (phony files notwithstanding). It is hard and painful if you want outputs to rely on and rebuild from configuration in the makefile itself. It's not impossible to implement, but it's difficult to precisely implement it: often times I've seen systems that just rebuild…
That is not portable make, rather GNU Make.
Earlier quoted context omitted.
> Window's users, on the other hand, still call their PC computers. I guess that is ok if computers are appliances. It seems that 90% of computer use has moved into the web browser. Heck outside of writing code, almost everything I do is in a browser, and my code editor of choice happens to be built as fancy skinned web browser... > To clarify, beneath the GUI interface is the actual code that implements that interfa…
> It seems that 90% of computer use has moved into the web browser. This is an extremely (web) developer-centric viewpoint IMHO. Try telling 3D modellers/sculptors, games programmers, audio engineers that 90% of their computer use has moved into a browser. They will look at you with a blank face since they all require traditional "fat" desktop apps to get their work done at professional level. And those are just the…
I'm talking about overall computer use. For certain professional fields, yes, apps still matter. But I'd take a guess that the majority of screen time with computers now days involves a web browser.
Heck as a programmer (not web), I am probably 50% in browser looking things up.
At most offices, computers are used for web browsing, and Microsoft Office.
Earlier quoted context omitted.
Every project I develop is unit tested with strings containing invalid unicode text, containing null bytes, and other random stuff. If a user can’t paste any byte sequence, and expect it to work, then the tool is broken. I handle these cases.
You can do it. The question is whether you should if you can avoid it. When writing a shell script or makefile to deal with repetitive tasks if is easier to assume some things.
Even bash lets you escape unusual filenames for when you need them. Make will always explode your strings, and doesn't even attempt to let you escape them. I don't think it's unreasonable to expect a time-tested Unix tool dealing with files to actually handle all possible files.