Create directory structure for multiple binaries

[atc0005]

Will have to look into the cmd subdirectory structure that I have seen on occasion.

[atc0005]

Ideas for building multiple binaries:

• https://ieftimov.com/post/golang-package-multiple-binaries/
• https://stackoverflow.com/questions/50904560/how-to-structure-go-application-to-produce-multiple-binaries/50904959
• https://stackoverflow.com/a/37681238
  • https://github.com/coreos/torus/blob/master/Makefile
  • this is probably somewhat the direction I'll need to consider going in?
  • https://github.com/grafana/grafana/blob/master/Makefile
• https://stackoverflow.com/a/50904959
  • this one reiterates the directory structure that I think we'll want to use here.

[atc0005]

Regarding cmd/NAME patterns, here is an example of what the official Nagios plugins are called:

• check_apt
• check_breeze
• check_by_ssh
• check_clamd
• check_cluster
• check_dhcp
• check_dig
• check_disk
• check_disk_smb
• check_dns
• check_dummy
• check_file_age
• check_flexlm
• check_ftp
• check_hpjd
• check_http
• check_icmp
• check_ide_smart
• check_ifoperstatus
• check_ifstatus
• check_imap
• check_ircd
• check_jabber
• check_load
• check_log
• check_mailq
• check_mrtg
• check_mrtgtraf
• check_nagios
• check_nntp
• check_nntps
• check_nt
• check_ntp
• check_ntp_peer
• check_ntp_time
• check_nwstat
• check_oracle
• check_overcr
• check_ping
• check_pop
• check_procs
• check_real
• check_rpc
• check_sensors
• check_simap
• check_smtp
• check_snmp
• check_spop
• check_ssh
• check_ssl_validity
• check_ssmtp
• check_swap
• check_tcp
• check_time
• check_udp
• check_ups
• check_uptime
• check_users
• check_wave
• negate
• urlize

refs https://nagios-plugins.org/doc/man/index.html

[atc0005]

Maybe check_imap_mailbox? The check_ssl_validity plugin name already sets a precedence for length. Not sure what the usual patterns are in the Go community however.

[atc0005]

Not sure what the usual patterns are in the Go community however.

Particularly the underscores.

[atc0005]

A very small, very brief search seems to indicate that dashes are used in longer cmd directory names. I'll go that direction for now.

[atc0005]

A very small, very brief search seems to indicate that dashes are used in longer cmd directory names. I'll go that direction for now.

This is what served as a springboard for light comparison:

It's common to have a small main function that imports and invokes the code from the /internal and /pkg directories and nothing else.

Examples:

• https://github.com/heptio/ark/tree/master/cmd (just a really small main function with everything else in packages)
  • https://github.com/moby/moby/tree/master/cmd
  • https://github.com/prometheus/prometheus/tree/master/cmd
  • https://github.com/influxdata/influxdb/tree/master/cmd
  • https://github.com/kubernetes/kubernetes/tree/master/cmd
  • https://github.com/satellity/satellity/tree/master/cmd/satellity
  • https://github.com/dapr/dapr/tree/master/cmd

refs https://github.com/golang-standards/project-layout/tree/master/cmd

[atc0005]

These projects appear to use a layout similar to what I'm looking to do here:

• https://github.com/go-task/task
• https://github.com/taskctl/taskctl

[atc0005]

Something to keep in mind:

How are these projects (if any have multiple binaries) handling their documentation, build requirements list, etc?

Is the main README super thin with forwarding links to docs in a single subdirectory, many subdirectories, alongside the code within cmd/NAME1/?

[atc0005]

Another example here:

https://github.com/jedib0t/go-pretty

[atc0005]

And yet another example:

https://github.com/cli/cli

Their Makefile:

BUILD_FILES = $(shell go list -f '{{range .GoFiles}}{{$$.Dir}}/{{.}}\
{{end}}' ./...)

GH_VERSION ?= $(shell git describe --tags 2>/dev/null || git rev-parse --short HEAD)
LDFLAGS := -X github.com/cli/cli/command.Version=$(GH_VERSION) $(LDFLAGS)
LDFLAGS := -X github.com/cli/cli/command.BuildDate=$(shell date +%Y-%m-%d) $(LDFLAGS)
ifdef GH_OAUTH_CLIENT_SECRET
    LDFLAGS := -X github.com/cli/cli/context.oauthClientID=$(GH_OAUTH_CLIENT_ID) $(LDFLAGS)
    LDFLAGS := -X github.com/cli/cli/context.oauthClientSecret=$(GH_OAUTH_CLIENT_SECRET) $(LDFLAGS)
endif

bin/gh: $(BUILD_FILES)
    @go build -ldflags "$(LDFLAGS)" -o "$@" ./cmd/gh

test:
    go test ./...
.PHONY: test

site:
    git worktree add site gh-pages

site-docs: site
    git -C site pull
    git -C site rm 'manual/gh*.md' 2>/dev/null || true
    go run ./cmd/gen-docs site/manual
    for f in site/manual/gh*.md; do sed -i.bak -e '/^### SEE ALSO/,$$d' "$$f"; done
    rm -f site/manual/*.bak
    git -C site add 'manual/gh*.md'
    git -C site commit -m 'update help docs'
    git -C site push
.PHONY: site-docs

[atc0005]

https://github.com/MartinHeinz/go-project-blueprint

Had it as an open tab, I recall wanting to dig further into it. Not sure if it is relevant here.

[atc0005]

refs atc0005/elbow#233 (and multiple other projects)

[atc0005]

From https://github.com/coreos/torus/blob/b53b701fc3af89fdf5f2999ebbc3b778e8c18ccc/Makefile#L11-L16:

WHAT := torusd torusctl torusblk

build: vendor
    for target in $(WHAT); do \
        $(BUILD_ENV_FLAGS) go build $(VERBOSE_$(V)) -o bin/$$target -ldflags "-X $(REPOPATH).Version=$(VERSION)" ./cmd/$$target; \
    done

Essentially each section would contain a similar loop to build/process each binary.