Currently if the target is too long it looks funny. Grab the longest and use its width.

Consider two local files Makefile and foo.mk

Makefile:

include foo.mk

foo.mk

foo:
	@echo "foo"

make allows including the local file, but mmake seems to think it's a remote include.

$ make foo
foo
$ mmake foo
   ⨯ installing                error=installing "foo.mk": only github.com is currently supported

Need a way to refresh the contents

Might be cool to have, for a quick glance at what the makefile does instead of going through every command :)

$ make help -v

  start:
    Start the dev server.

    Note that the API server must
    also be running.

  api:    
    Start the API server.

  deps:       
    Display dependency graph.

  size:
    Display size of dependencies.

@tj , thanks for this awesome tooling.
I'm not sure if this was ever possible. But in 1.3.0 mmake help does not output any help data for a simple included common makefile.

Makefile

include ../common.mk

common.mk

# example command help string
start:
  @echo test
.PHONY: start

Many style guides suggest putting the .PHONY before the target.
This is also my preferred style.

# Remove all build artifacts and dependencies
.PHONY: clean
clean:
	-rm -r build

This, however, leads to a not very helpful help output

$ make help

  .PHONY                        Remove all build artifacts and dependencies

I think mmake should ignore the .PHONY line.

I was thinking about how to use mmake with projects where potential contributors may or may not have it, and asking them to install it is another step that doesn't feel totally necessary. The idea I came up with is to have a secondary MMakefile (or similar) that contains remote includes, and can (optionally) be used to generate a Makefile with the remote includes inlined.

For instance:

# MMakefile

include github.com/foo/make/bar

$ mmake gen

# Makefile

bar:
    // Contents of github.com/foo/make/bar

Basically mmake would check for MMakefile before Makefile when executing a target, so you could have either a MMakefile, Makefile, or both.

Alternatively, it could suffice to support overwriting a target in a Makefile with the latest version of a remote. For example, the sanity and precommit targets here are actually copy+pasted from what would have been remote includes if I were to enforce mmake being installed, which isn't ideal because there are already hurdles to contributing to that project. What would be nice is to be able to update these targets inline with the latest contents of the remote targets, something like:

$ mmake update sanity github.com/KyleBanks/make/go/sanity

After this the Makefile would contain the latest version of sanity.

This was installed using homebrew.

$ cat Makefile | head -1
include https://gitlab.com/REDACTED/make-templates.git

$ make
   ⨯ installing                error=installing "https://gitlab.com/REDACTED/make-templates.git": mkdir: mkdir /usr/local/include: permission denied

I'm thinking this is an issue with M1 Mac's and how homebrew changed the install directory: /usr/local vs /opt/homebrew

Also tried installing with curl:

$ curl -sf https://gobinaries.com/tj/mmake/cmd/mmake | sudo sh
Password:

  ==> Downloading github.com/tj/mmake/cmd/mmake@master
  ==> Resolved version master to v1.4.0
  ==> Downloading binary for darwin arm64

  Error downloading, got 500 response from server

$ sw_vers
ProductName:	macOS
ProductVersion:	12.4
BuildVersion:	21F79

Somewhere I have code to parse the wiki pages for listing/search etc via CLI.

Right now if we run Makefile via mmake for the first time it fetches github.com includes, it might be cool to have some kind of info / spinner running, dunno..

Since this exists, might as well be used here: https://github.com/tj/go-spin :p

my lazy tree commands appear to be failing, the output looks like it's matching just fine but something is going on there

In your .goreleaser configuration you have homebrew configured, but you haven't yet published the formula. I would love to be able to install mmake via brew. Could you publish your formula?

Currently just ignoring them entirely, but ideally we traverse those as well and pick up any local includes / comments.

Hi @tj,

I like the concept of this project and looked through forks and PRs to bring it current and extend it for a few desired features. Repo: https://github.com/zph/mmake

• Allow direct http/s based includes via new resolver
• Support standard makefile names (per GNUMake, ie GNUmakefile, makefile, or Makefile) #33 (though I rewrote this one myself)
• Allow custom include paths #25
• Highlight default target #29
• Fixed tests broken by custom include path.
• Use goreleaser
• Setup a brew recipe for installation on mac/linux
• Use golang modules for dependency tracking/download
• Implements #3 tag/commit/sha support for github based resolver

I want to make sure to contribute back and am happy to do any of the following:

• Merge this back into your repo and optionally get a commit bit to tidy up the issues/PRs
• Maintain my own copy indefinitely
• Or another combination of these :).

Thanks for putting this project together and if any of these outcomes sound good, great! If not, I'm quite happy to have my own repo for it too 👍.

Cheers,
ZPH

Now that they're sorted it's not obvious.

make help for all, make help stage for stage* prefix etc

Looks like the parser might need more complexity for this, but just wanted to throw out a vote for displaying a build dependency tree.

I use make for a number of ETL tasks, and it would be nice to easily see what files/targets might be touched before I do something that will take a long time.

Maybe. It would be nicer for local hacking.

Be cool to pretty print duration between targets and such

https://stackoverflow.com/questions/37725552/show-the-build-duration-time-in-makefile is rather nasty

that is the only feature from makefiles that I would miss