Go command support for "make"

[Lucio]

I'm hoping this already has an answer, rather than require additional features. I also don't expect this to be a popular request, but I do consider its merits as greater than the disadvantages, so here goes.

Efforts to eliminate the use of the Unix "make" command by producing a vastly more modern "go" command have been valiant and largely successful, in my opinion, at least, but I personally come up short on a regular basis, perhaps because I don't really know the "go" command as intimately as I ought to.

As soon as I need a slightly unusual target in a development environment, I am prone to add an entry in a Makefile (actually "mkfile" as most of my development occurs in a Plan 9 environment), but I come against a barrier: I need to determine not only if local modules are more recent than the target, but also if related modules in imported packages are fresher than the target.

I don't mind having to list the packages involved, ideally by the label I use within the code for each of them, that is acceptable. What I don't know how to do and suspect may need a small enhancement to the "go" command, is to reach into each package (directory) and verify that it is or is not reason to rebuild the target.

What I just realised is that my Makefile/mkfile-foo isn't sufficient to *do something* with such information, but at this point I'm willing to cross that bridge when I come to it. For now, having a "go status infernal/package", say, even if it provides a single reply: "updated=yes", for example (someone here will think of a better approach, no doubt) will be a useful start. Obviously, the command is run in a directory other than the one being verified.

Suggestions, from anyone, on how to do something like that? I don't mind getting my fingers dirty, but I'm hoping for the direction that makes such a facility as useful to as many Gophers as possible.

Lucio.

[Sam Whited]

On Wed, Mar 20, 2019, at 05:05, Lucio wrote:
> What I just realised is that my Makefile/mkfile-foo isn't sufficient
> to *do something* with such information, but at this point I'm willing
> to cross that bridge when I come to it. For now, having a "go status
> infernal/package", say, even if it provides a single reply:
> "updated=yes", for example (someone here will think of a better
> approach, no doubt) will be a useful start. Obviously, the command is
> run in a directory other than the one being verified.

Make files are meant to check if one file is newer than another, not the
output of a command. If you want to see if your dependencies have been
updated or not, check if the file that contains those dependencies has
been updated (eg. go.mod or Gopkg.toml). If you want to check if local
files have been updated, list those local files. Something like this is
a good start for a Go project (assuming you want to depend on all .go
files in the project, which may or may not be a good assumption
depending on the project).

GOFILES!=find . -name '*.go'

yourbinary:
go.mod $(GOFILES) go build -o $@

—Sam

[Ian Lance Taylor]

At first glance "go status internal/package" sounds like

test $(go list -f '{{.Stale}}' internal/package$) = "true"

If that doesn't work, can you explain what additional functionality
you're looking for?

Ian

[Paul Jolly]

Hi Ian,

> test $(go list -f '{{.Stale}}' internal/package$) = "true"

Does .Stale still have meaning/is it still accurate in a build cache world?

[Ian Lance Taylor]

On Wed, Mar 20, 2019 at 7:01 AM Paul Jolly <pa...@myitcv.io> wrote:
>
> > test $(go list -f '{{.Stale}}' internal/package$) = "true"
>
> Does .Stale still have meaning/is it still accurate in a build cache world?

I doubt it, but I'm not sure the original question has any meaning in
that world. In a build cache world there's no reason to ever ask
whether something is up to date. You just unconditionally run
whatever command is required to make it up to date.

Ian