4 ms·

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

by Too 12y ago

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 knowing all the 150 flags of whatever build chain of the day. This does not mean invoking compile manually on every file but you you invoke the smallest possible build file for your intended platform just for building and absolutely nothing else. Compiling c projects without make would otherwise take hours instead of minutes. Really, Gradle requires you to read the first 12 chapters of the manual before you can even begin doing something more advanced than running compile. Msbuild likewise, it's like a completely new programming language just that it's written in xml. Bamboo is just like imperative programming except you have to drag and drop boxes that invokes commands or plugins (yep, another plugin hell). CMake works kindof painlessly but it also requires a lot of black magic when you want to add dependencies outside of the c buildchain. The only one that actually doesn't make you cry is 'make' because it's so simple, it's just doing one thing instead of trying to tie itself into the entire ecosystem badly. Make also has it's problems but when you start hitting those it's more of a sign that you are trying to add too much weird logic that should not be in the build script to begin with.

jbergens 12y ago
You still have to get all tools to all build environments (developer computers, build servers). For javascript you can write the build script in javascript without Gulp, Broccoli or Grunt, it works great. But you still want some tools to be installed and then you probably start to use NPM anyway.
bad_user 12y ago
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 things are standard stuff that one would like to do for every project. It's unfathomable why anybody would want to do this manual plumbing for each project with Make. You call Make "simple", I call it "dumb" and it's the reason for why people end up with aberrations of nature, such as Autotools. > Gradle requires you to read the first 12 chapters of the manual before you can even begin doing something more advanced than running compile You're exaggerating. Compiling a project is a hello world of a couple of lines. What "advanced" usage are you talking about anyway?
- fit2rule 12y ago
  >And you know, these things are standard stuff that one would like to do for every project And its totally stupid, and the stupid persists, because 'its standard' now. This is how stupid stuff becomes standard - people say "hey, this stupid stuff - its standard now". You're using the argument that its a good thing to have to do all of that stuff with one tool .. really? (Besides, Make can do all of that - you just have to configure it to do so, like any other tool..)
- vidarh 12y ago
  > Make doesn't do incremental building 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.
pjmlp 12y ago
> The only one that actually doesn't make you cry is 'make' because it's so simple, I imagine you never wrote Make scripts that had to be portable.
cowls 12y ago
Hmm, I don't think not fully understanding existing tools and not wanting to read documentation is a good reason. You can easily add prompting with maven, gradle etc, test result reporting, source control integration is all built in. 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
icantthinkofone 12y ago
It's interesting to watch the commentors to your post say the way to fix the problems with tools is with a tool to fix the tool which is at least one of the issues outlined in the article.
vorg 12y ago
> Gradle requires you to read the first 12 chapters of the manual before you can even begin doing something more advanced than running compile The purpose of Gradle, like other products in the Groovy echosystem, is to sell consulting fees and conference seats for their backers, in this case Gradleware. Hence providing easy-to-use doco would defeat the point of the product.

by Too 12y ago

jbergens 12y ago

You still have to get all tools to all build environments (developer computers, build servers). For javascript you can write the build script in javascript without Gulp, Broccoli or Grunt, it works great. But you still want some tools to be installed and then you probably start to use NPM anyway.

bad_user 12y ago

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 things are standard stuff that one would like to do for every project. It's unfathomable why anybody would want to do this manual plumbing for each project with Make. You call Make "simple", I call it "dumb" and it's the reason for why people end up with aberrations of nature, such as Autotools. > Gradle requires you to read the first 12 chapters of the manual before you can even begin doing something more advanced than running compile You're exaggerating. Compiling a project is a hello world of a couple of lines. What "advanced" usage are you talking about anyway?

fit2rule 12y ago
>And you know, these things are standard stuff that one would like to do for every project And its totally stupid, and the stupid persists, because 'its standard' now. This is how stupid stuff becomes standard - people say "hey, this stupid stuff - its standard now". You're using the argument that its a good thing to have to do all of that stuff with one tool .. really? (Besides, Make can do all of that - you just have to configure it to do so, like any other tool..)
vidarh 12y ago
> Make doesn't do incremental building 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.

pjmlp 12y ago

> The only one that actually doesn't make you cry is 'make' because it's so simple, I imagine you never wrote Make scripts that had to be portable.

cowls 12y ago

Hmm, I don't think not fully understanding existing tools and not wanting to read documentation is a good reason. You can easily add prompting with maven, gradle etc, test result reporting, source control integration is all built in. 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

icantthinkofone 12y ago

It's interesting to watch the commentors to your post say the way to fix the problems with tools is with a tool to fix the tool which is at least one of the issues outlined in the article.

vorg 12y ago

> Gradle requires you to read the first 12 chapters of the manual before you can even begin doing something more advanced than running compile The purpose of Gradle, like other products in the Groovy echosystem, is to sell consulting fees and conference seats for their backers, in this case Gradleware. Hence providing easy-to-use doco would defeat the point of the product.