On Wednesday, 26 February 2020 20:53:52 UTC+1, geoff.j...@gmail.com wrote:
>
> This baffles me:
>
>
> $ go build foo.com/foobar
> can't load package: package foo.com/foobar: cannot find module providing
> package foo.com/foobar
>
>
You simply cannot build a module. Only packages can be built.
and there is no package at the root of your module. Try
cd cmd/foo; go build
or go build foo.com/foobar/cmd/foo
> $ head -1 go.mod
> module foo.com/foobar
>
> $ go list -m foo.com/foobar # but this finds it perfectly well?
>
> Yes. You are asking questions about a module and this
question is answered.
> although this seems to work:
>
>
> $ GOBIN=/some/path go install ./...$ find /some/path -type
> f/some/path/foo/some/path/bar
>
> Well sure. Asked to build every package and that was done.
> [... larger rant on the tooling ...]
>
> So:
>
>1.
>
>I don’t understand why go build foo.com/foobar fails to find the
>module if it doesn’t contain some top-level .go file, but go list -m
>finds it perfectly fine.
>
> The error message clearly is suboptimal and I think there is
an issue already for that. Just pick it up and fix it.
Note that what you asked the go tool to do is not
something it can do. The go tool operates on packages
during build, install, test, etc. and not on modules.
>
>1.
>
>[How] can I have a module X that provides packages X/Y and X/Z, with
>no source files in the top-level package X? Or am I not supposed to do
>this under Go modules?
>
> Just like you did. Everything works just fine, you just
cannot ask the go tool to build or install the module.
You noticed that module stuff works properly without
*.go files in the module root.
Remember: A module is a collection of packages versioned
together and their dependencies.
>
>1.
>
>Go modules appear to break my assumption that “I just set GOOS and/or
>GOARCH to cross-compile, and everything else just works”. The is
>(was?) one of the biggest benefits of Go for me. I need to cross-compile
>for Linux (ARM, AArch64 and AMD64) and Windows (AMD64) all the time.
>
> I do not see how modules infer with cross-compilation.
I doubt you could set GOBIN in GOPATH mode either
>
>1.
>
>Cross-compiled go install to some non-global output directory worked
>fine in GOPATH days: creating $GOPATH/bin/$GOOS-$GOARCH/*, which
>seemed perfectly sensible to me. I don’t understand why it’s broken under
>modules, particularly when I set GOBIN, which I take to mean “Put the
>binaries here please: I know what I’m doing; please don’t argue”. Or at
>least have some sort of -yes-really flag to stop the toolchain arguing.
>
> You should probably address this on the issue tracker.
>
>
> At the moment I can see two solutions:
>
>1.
>
>Split up my project into individual modules for the shared code (or
>even every package therein), and each executable. Since none of those
>components, in this context, makes sense individually, this seems like the
>tail wagging the dog.
>2.
>
>Revert to using GOPATH and hope that it never gets removed. History
>teaches me that this is unwise.
>
> but I can’t help thinking that I’m doing something fundamentally wrong.
> I’ve read the docs, help pages, Wiki et cetera, and found nothing that has
> helped me. Can someone please put me right?
>
I do not see why doing a simple mkdir before running go install
would be a no-go. It might take a handful of more commands
to crosscompile multiple executables from a module but nothing
rocket science. If typing these command annoys you: put the in
a shell script.
V.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/8d6b726a-fa19-4ee9-8143-7603233d0ccc%40googlegroups.com.
