5 ms·

> It is NOT a repository for "dev commands" whatever the hell that means. What it means is that it doesn't matter if I run `make test`, my coworker runs `make

> It is NOT a repository for "dev commands" whatever the hell that means. What it means is that it doesn't matter if I run `make test`, my coworker runs `make test` or the CI system runs `make test`, we all end up with the same result. Namely that the test suite will be run, after all stuff is done that is needed to setup the dev environment. Basically you codify all actions you as a developer would need, to setup, verify or use a project and all the dependencies between them. This makes your projects portable and when you have multiple projects (in different languages), getting it setup and running the test suite is the same for each one of them. Why not use a bash script? That's how I started off but once a coworker introduced me to Make I never looked back. Bash scales really badly in terms of readability and maintainability.

Arch-TK 5y ago
Right, I wasn't asking what "single source of truth is" I was asking what a "dev command" is. If you have commands and you want to store them so that multiple people can run them then the solution is NOT make, using make to execute commands is really quite like using machine gun to turn your TV on. Make is a very big and complex tool with lots of nuance and lots of different and not-cross-compatible versions. Moreover, it doesn't always use the same shell on every machine you run it on so using it to store bash scripts (for example) isn't really portable either. I'm sorry to be the one to tell you this but neither you nor your coworker know what make is if all you think it is is a way to store subcommands. If you want shell scripts write shell scripts. If you want them all to stem from one command (as subcommands), use a switch statement. These solutions will actually likely be far more reliable and portable (if you know what you're doing, I would imagine it's easier with portable shell than portable shell in make since even most of the programmers I know who use make for the purpose it was designed for don't seem to understand it very well).
- aequitas 5y ago
  Take a look at one of my Makefiles[0]. It uses most features Make has to offer (to much so). It doesn't matter what state you start from, fresh clones repo or outdated virtualenv. Running `make run` will do everything needed to run the application instance, `make test` will run the testsuite. Each command is it's own "functional" block of shell script with it's inputs (prerequisites) and outputs (target). All recipies will run in Bash on all system btw, see the first line of the Makefile. Still, a Makefile with only targets, no prerequisites is less cruft than a Bash script with a switch statement. But eventually your (team) needs will grow and you start to introduce more logic and dependencies. This is where Make shines for me. [0] https://gitlab.com/internet-cleanup-foundation/web-security-map/-/blob/master/Makefile https://gitlab.com/internet-cleanup-foundation/web-security-...
  - Arch-TK 5y ago
    "Dependencies" in your makefile are literally just functions. This can literally all be done with a bash script and 100% less backslashes to make things run in one shell. I really seriously think that this would be much cleared if written in bash. That being said, while perusing the original makefile I found multiple issues. The one which stands out the most is that running make with a -j flag (which is entirely likely if your end user aliases that in their bashrc, I know multiple people that do). I am pretty sure fix and test can't run concurrently, at least I can't imagine how in-place fixing of files while running tests would work reliably. There's probably more cases where this would break things. Another issue is using `echo -e` and other bashisms, except that it's not guaranteed make will be running bash. I really don't understand why your makefile keeps creating files, if it didn't create most of those files it would behave basically identically except for not needing to periodically run clean. In fact, by not providing a full DAG your makefile is just annoying in that there really isn't any option other than deleting random files or redoing all the steps. I don't see how having to delete .make.test and running make test is any better than having ./run-testsuite or ./run testsuite just run the testsuite every time. Edit: I noticed your makefile sets SHELL. But this will in turn break this line: https://gitlab.com/internet-cleanup-foundation/web-security-map/-/blob/master/Makefile#L60 https://gitlab.com/internet-cleanup-foundation/web-security-...
    - aequitas 5y ago
      I think you are missing a fundamental feature of what makes Make special, which is how it handles dependencies. It uses file timestamps to decide what to do and especially what things to skip because they don't need to be done. All those .make.* files serve a purpose, as Make will compare the timestamp of those files to the prerequisite files (source files) and only run the shell scripts if they are outdated (in the process recreating the target with an updated timestamp). So if I didn't change any of the source files, there is no need to lint or test again, since nothing changed, there can be no different result. Same goes for installing requirements (a lengthy task). If the requirements files don't change, nothing needs to be reinstalled. But if I pull in new changes from a colleague with an updated requirements files, running any Make target that has a dependency on those requirements will run the scripts to update them without me having to think about it.

Arch-TK 5y ago

Right, I wasn't asking what "single source of truth is" I was asking what a "dev command" is. If you have commands and you want to store them so that multiple people can run them then the solution is NOT make, using make to execute commands is really quite like using machine gun to turn your TV on. Make is a very big and complex tool with lots of nuance and lots of different and not-cross-compatible versions. Moreover, it doesn't always use the same shell on every machine you run it on so using it to store bash scripts (for example) isn't really portable either. I'm sorry to be the one to tell you this but neither you nor your coworker know what make is if all you think it is is a way to store subcommands. If you want shell scripts write shell scripts. If you want them all to stem from one command (as subcommands), use a switch statement. These solutions will actually likely be far more reliable and portable (if you know what you're doing, I would imagine it's easier with portable shell than portable shell in make since even most of the programmers I know who use make for the purpose it was designed for don't seem to understand it very well).

aequitas 5y ago
Take a look at one of my Makefiles[0]. It uses most features Make has to offer (to much so). It doesn't matter what state you start from, fresh clones repo or outdated virtualenv. Running `make run` will do everything needed to run the application instance, `make test` will run the testsuite. Each command is it's own "functional" block of shell script with it's inputs (prerequisites) and outputs (target). All recipies will run in Bash on all system btw, see the first line of the Makefile. Still, a Makefile with only targets, no prerequisites is less cruft than a Bash script with a switch statement. But eventually your (team) needs will grow and you start to introduce more logic and dependencies. This is where Make shines for me. [0] https://gitlab.com/internet-cleanup-foundation/web-security-map/-/blob/master/Makefile https://gitlab.com/internet-cleanup-foundation/web-security-...
- Arch-TK 5y ago
  "Dependencies" in your makefile are literally just functions. This can literally all be done with a bash script and 100% less backslashes to make things run in one shell. I really seriously think that this would be much cleared if written in bash. That being said, while perusing the original makefile I found multiple issues. The one which stands out the most is that running make with a -j flag (which is entirely likely if your end user aliases that in their bashrc, I know multiple people that do). I am pretty sure fix and test can't run concurrently, at least I can't imagine how in-place fixing of files while running tests would work reliably. There's probably more cases where this would break things. Another issue is using `echo -e` and other bashisms, except that it's not guaranteed make will be running bash. I really don't understand why your makefile keeps creating files, if it didn't create most of those files it would behave basically identically except for not needing to periodically run clean. In fact, by not providing a full DAG your makefile is just annoying in that there really isn't any option other than deleting random files or redoing all the steps. I don't see how having to delete .make.test and running make test is any better than having ./run-testsuite or ./run testsuite just run the testsuite every time. Edit: I noticed your makefile sets SHELL. But this will in turn break this line: https://gitlab.com/internet-cleanup-foundation/web-security-map/-/blob/master/Makefile#L60 https://gitlab.com/internet-cleanup-foundation/web-security-...
  - aequitas 5y ago
    I think you are missing a fundamental feature of what makes Make special, which is how it handles dependencies. It uses file timestamps to decide what to do and especially what things to skip because they don't need to be done. All those .make.* files serve a purpose, as Make will compare the timestamp of those files to the prerequisite files (source files) and only run the shell scripts if they are outdated (in the process recreating the target with an updated timestamp). So if I didn't change any of the source files, there is no need to lint or test again, since nothing changed, there can be no different result. Same goes for installing requirements (a lengthy task). If the requirements files don't change, nothing needs to be reinstalled. But if I pull in new changes from a colleague with an updated requirements files, running any Make target that has a dependency on those requirements will run the scripts to update them without me having to think about it.