71–80 of 108 posts
EDIT: Also a HN submission by the author himself: https://news.ycombinator.com/item?id=8721929
I found all build systems for all platforms to be a total PITA and eventually i just resort to using a shell or python script to invoke the commands i want. With this method you can very easily add user promting (do you want to build debug or release?), database reporting of build and test results, source control integration etc. Whatever i learn here can be applied and reused for new things in the future instead of…
I imagine you never wrote Make scripts that had to be portable.
I simply use Make for all my web projects, whether it's a Ruby JSON API, or a React front-end. It's reliable, pre-installed everywhere, and can wrap anything in one consistent CLI. Why have to remember whether to type lein repl , pry , or rails console , when make repl will do everytime? Ditto, bundle install , npm install , lein deps => make deps . make server can easily wrap whatever command launches the server, ma…
keep in mind that make isn't going to work on Windows. For a lot of people, that's okay (including myself). Still, a ton of developers still work on Windows.
Unless you make sure only to use these features
http://pubs.opengroup.org/onlinepubs/009695399/utilities/mak...
Same thing for any external tool used in the scripts.
I found all build systems for all platforms to be a total PITA and eventually i just resort to using a shell or python script to invoke the commands i want. With this method you can very easily add user promting (do you want to build debug or release?), database reporting of build and test results, source control integration etc. Whatever i learn here can be applied and reused for new things in the future instead of…
You cannot compare something like Maven/Gradle/SBT/Leiningen to Make. Make doesn't do incremental building and testing, it doesn't do test coverage reports, it doesn't download the dependencies for you, it doesn't build the Javadoc documentation for you, it does not package and publish your signed artifacts on Maven Central, it does not wrap your stuff in an OS specific installer, etc, etc... And you know, these thin…
Say what? That's one of the main purposes of make.
> it doesn't do test coverage reports, it doesn't download the dependencies for you, it doesn't build the Javadoc documentation for you, it does not package and publish your signed artifacts on Maven Central, it does not wrap your stuff in an OS specific installer, etc, etc...
... without the appropriate rule supported by whatever tools you prefer. Which you, once you have a workflow that works for you, can put in a file and include by reference in your makefiles going forward.
It's perfectly possible it's simpler for you to use one of the tools you list than doing so, but the nice things about relying on basic make is that very often people will want to tweak your assumptions about what "one would like to do for every project":
> And you know, these things are standard stuff that one would like to do for every project.
Most of what you listed is stuff that I rarely want to do, and some of them are things I've never done.
> I call it "dumb" and it's the reason for why people end up with aberrations of nature, such as Autotools.
The reason people end up with evil stuff like autotools is usually to (try) handle platform API differences, not usually to handle any of the stuff you listed. We seem to agree that Autotools is an awful mess, though.
I found all build systems for all platforms to be a total PITA and eventually i just resort to using a shell or python script to invoke the commands i want. With this method you can very easily add user promting (do you want to build debug or release?), database reporting of build and test results, source control integration etc. Whatever i learn here can be applied and reused for new things in the future instead of…
The 150 flags you mention provide flexibility, you dont need to know them all to get started. With your custom build process, instead of finding a flag that does what you need, you need to implement what you need from scratch, and document it for future developers.
If you use a standard build tool its also easier to hire someone who already knows it, plus understanding them will help you fit into new teams easier.
Unless maybe this is for personal projects, in which case I think its probably less of an issue
Why don't people just use make?
Each make has it own set of extensions outside of what POSIX requires.
Additionally, for almost every task you need to call out to external tools that also have their own set of compatibility issues across UNIX/POSIX systems.
Ideally everyone writing a Make script would need to read the POSIX standard and only use common features, but since that isn't the case, scripts break across systems.
This is what lead to autotools/autoconf creation.
Why don't people just use make?
Because it isn't portable, not even across UNIX/POSIX systems. Each make has it own set of extensions outside of what POSIX requires. Additionally, for almost every task you need to call out to external tools that also have their own set of compatibility issues across UNIX/POSIX systems. Ideally everyone writing a Make script would need to read the POSIX standard and only use common features, but since that isn't the…
How many realistic development choices fall in that category? Is anyone actually doing development on IRIX or UNICOS?
Earlier quoted context omitted.
You (and the rest of the comments to your post) miss the point: Now you need grunt, a gruntfile, the tools for the build process and grunt specific wrappers. What you instead could have had was a simple script running the tools with the proper command line arguments.
Are you also against make, cmake, mvn, rake, etc...? Those tools could also be replaced with custom scripts, but programmers in every language seem to agree that build tools make the job easier. I don't think grunt or gulp are perfect, but do think they make writing, organizing, and reusing build tasks easier. So are just against gulp/grunt, or really are opposed to the whole idea of a JavaScript build tool?
Make would basically just run CLI in this instance, so it's exactly what I like. I like maven, but I hate when I need a special maven plugin for the tool I want to use. All these tools expose a nice CLI that can be used, no need to complicate it by adding more abstractions. If it weren't for how Grunt can watch files, I would have scrapped it for our project. Because the config Gruntfile for our build process is impossible to understand and maintain, but the end results are just some simple commands to various tools.
Earlier quoted context omitted.
keep in mind that make isn't going to work on Windows. For a lot of people, that's okay (including myself). Still, a ton of developers still work on Windows.
Actually make isn't even fully portable across POSIX systems. Unless you make sure only to use these features http://pubs.opengroup.org/onlinepubs/009695399/utilities/mak... Same thing for any external tool used in the scripts.