142 points | by timz2 months ago
Make does:
- topological sorting based ordering of the dependency tree
- skipping of already up to date targets
- supports parallel execution of independent dependency subtrees
The webpage is totally unclear on this, and to me it looks like it only allows for a named entrypoint to some script snippets.
I'm a literal programming fan though, and this is a nice start, but i recommend clarifying the docs on this.
And that’s frustrating, because the place where a make alternative could really shine is not in making the syntax for specifying scripts nicer, but in figuring out how to design the dependency APIs so that you aren’t almost guaranteed to get them wrong in subtle ways.
# [clean]() Clean build directory
```bash
rm -rf ./build
```
# [format]() Format the source code
```bash
npx prettier --write .
```
# [build](clean format) Build the project
```bash
npm run build
```
# [deploy](build) Deploy to surge.sh
```bash
surge ./build my-project.surge.sh
```
Thank you for feature suggestion.
It's possible to create makefile targets which say "Don't run this other target on my behalf, but if you're going to run it anyway then run it before me"; for example, don't try to create the build output directory every time you run this target, but if it does need to be created then create it first.
Every time I've tried to look for a clean, effective Makefile replacement there have either been obvious (to me) missing features that make anything but the most basic use cases tricky, or the system is so clearly designed to solve one specific problem (e.g. "compile a bunch of .c files into a binary") and as a result is unsuitable for most use cases that Makefiles would be good for.
I just do mine in bash (make.sh) and it runs scripts from make.d/ which are in whatever (python, js bash, PHP)
Aditionally we can generate html out of the, now `makedown.md`, right in the tool: $ makedown --html makedown.html or $ m --pdf makedown.pdf
But without the “building” component to it, I found the name makedown confusing. Maybe that’s just me.
But I like the project overall. I’m still trying to get my head around the syntax, but it looks nice. I’m also not sure I’ll switch from keeping scripts like this in my $HOME/.local/bin directory, but I can see how this is an appealing way to work.
It’s not just for C!
(Although, it’s mainly used for C)
For one of my projects, I tried something similar where I had code blocks in README.md like:
Usage
-----
`pip install bar` and import `foo`:
```python
import foo from bar
```
Run `foo.alice` with default arguments:
```python
foo.alice()
```
Run `foo.bob` while specifying `baz`:
```python
foo.bob(baz=0)
```
.PHONY: demo
demo: venv
@. .venv/bin/activate; sed -n '/^```python/,/^```/p' < README.md | sed '/^```/d' | python
.PHONY: venv
venv: .venv/bin/activate requirements.txt
@. .venv/bin/activate; pip install -qU pip
@. .venv/bin/activate; pip install -qUr requirements.txt
.venv/bin/activate:
@python3 -m venv .venv
make demoI’m the creator of Mask[0], a very similar tool built with Rust. I was originally inspired by Maid[1], which is an older take on this idea built with Node and no longer maintained I believe.
I see this is based on Node as well, and I appreciate that it currently has zero dependencies. Nice work!
The stripped Docker containers are used mostly for runtime to my understanding, building is done in a different container where more build tools are available.
In case of single binary (now it is single python file), what would be the best way to distribute it to users, since pypi and npm cannot be used?
Which language you would suggest?
> Which language you would suggest?
Golang
Pretty sure Rust is only slightly less easy. No idea about Nim.
### [my-command-name]() My command short description
A longer command help
```typescript #!/usr/bin/env deno run console.log("hi") ```
if hashbang is missing, it is infered from the markdown codeblock lang speck, with fallback to bash.
Thank you for all the feedback
I used XC for a bit, which does a similar thing, but have since reverted to make. The self-documenting nature of these tools can be very useful.
If you have a README with a list of build tasks, it'll pull its content and give nicer names to whatever is placed in package.json scripts field.
(I'm using comments for that which feels clunky)
I don't update it often, but I still use it almost every day.
Maybe we can make the embedded code be "format independent" or have different embedding syntax to extract the code from various forms of docs? Technically Markdown is already a special case of plain ASCII text, so that's cool. But since Emacs Org Mode (which is supported even in VSCode via a plugin) we could have a way that's compatible with Org Mode as well? Or would that be replicating existing Org Mode features too much? I'm not experienced in Org Mode other than to prove that VSCode plugin works however, so that's why I have to ask.
One "hole" I've seen in all of modern software development is that you also normally have just documentation in the code comments, but no real linking of each code method (or function or class) to various other places in external documentation.
I know we have URLs for that, but it's usually too difficult to get URLs put into code that points to specific areas in the docs, and vice versa. And if you ask a developer a question like "What's the URL for the docs for this method" you'll get a blank stare because generally that concept doesn't exist.
Thanks for sharing!
## [clean]() Cleans the generated files
```bash
rm -rf ./build
```
## [init]() Initializes the build folder
```bash
mkdir -p ./build
```
## [build](clean, init) Builds the project
This command depends on clean, and init, which are executed in that order beforehand.
gcc magic.c -o ./build/magicI like what you're exploring, but it's not "make".
I like the idea and the execution. This bit though:
> makedown.sh
> npm install -g ...
> #!/usr/bin/env python
Gives me a bit of whiplash. I get wanting to use npm to install, since 1) lots of people have it installed and 2) it’s reasonably cross-platform and it seems like makedown is as well.
I don’t see a reason for it to be named makedown.sh instead of just makedown, though. Make itself doesn’t depend on sh to my knowledge, and you could have a makedown file with no shell build rules at all.
Recipes are run through sh by default, though it can be overridden to anything using the SHELL variable (including, say, python).
Agree with the idea already stated here to use <h2> elements instead of <h1>.
I assume that there is no support for the scripts having their own command-line arguments? Or how do you disambiguate?
Anyway, this seems like an interesting demo, but it's hard to imagine the use case.
What would be pros and cons of implementing it in:
- bash/zsh
- keep in python
- rust/go- better --help messages with or without command - ## level 2 headers are used - the temp file is created in current folder, like that importing npm modules from current project works
- can capture output and be updated & displayed in the markdown doc.
- persistent kernels
What do you mean by capture output, like if i have ```bash echo "hello" ``` hello would appear in the rendered markdown?
Persistent kernel: e.g. each ```python``` code block is the same interpreter process with all the same variables. Same for bash, etc. The process is kept open and lines to exec piped to it. Or use a wrapper like Jupyter kernels (example [1]). Have the ability to run/re-run a specific code block.
Output capture: Yes if you echo something it could appear in an output block following the code block. Very much like a Jupyter Notebook cell showing it's output. The simplest output capture is just text, but you could also figure out how to hook into things like matplotlib and show plots (e.g. option to allow the output to be shown as a markdown sub-section).
At the same time easy to edit and easy to enhance with different build languages as needed.