core tool could support a simple solution to the "main" vs. "library" dilemma

[rcoreilly]

Describe the feature

A constant challenge in Go is the inability to have a given directory contain both an executable and also be importable as a package for use elsewhere: https://groups.google.com/g/Golang-nuts/c/frh9zQPEjUk

If you want the executable to be named the same as the overall importable package, then you need two levels of subdirectories:

mypackage/
    mypackage.go
    ...
    cmd/
        mypackage/
            main.go
            mypackage  <- go build makes this

It would be great if you could instead just have this:

mypackage/
    mypackage.go
    ...
    cmd/
        main.go

and a core build or core run in the mypackage directory would automatically detect the presence of the cmd subdir, do a go build in that directory, and put the output back up at top level with the name mypackage.

How awesome would that be!?

This is actually a fairly urgent issue for me because I want all my sims to be accessible as imports into an overall content interactive doc space, and also available as a local executable command to run on a cluster etc.

I will implement in a PR now -- should take just a few mins.

Relevant code

No response

[rcoreilly]

@kkoreilly pointed out that you can just do this:

mypackage/
    mypackage.go
    ...
    mypackage/
        main.go

(or the reverse, with the main at the top and package code below)

in which case the standard go build will at least make the right exe name, which is a big part of the issue. I will add tooling to cogent code to detect this situation and basically handle the rest -- it makes sense to have this be at a higher level than core build.

[rcoreilly]

I thought that seemed too obvious to have overlooked this option before!

The problem is that I really want the exe to be in the upper level directory but then it is the same name as the subdirectory so that doesn't work at all.

[kkoreilly]

We still have not resolved how to do this; the commit above was reverted as it does not make sense for the core tool to do that.