Problem with migration to the new "module" technology from "go"

[Andreas Otto]

Hi,

I have an existing project existing of a "library" creating a wrapper to "C" using "go install" and on a different place multiple "executable's" everything glue

together using the GOPATH technology. NOW I start using the new "module" technology.

Library: 

1. I create with "mod init pkgname" my module
2. I build my library use both "go install" or "go build" and the build is done but NO final "pkg/*/pkgname.a" file is created → why?
3. If I use "go build -o pkgname.a ." I get my "pkgname.a" and I can place it everywhere I want.

Executable:

1. I create with "mod init example" a module in the directory using multiple "main" go files
2. NOW I have the problem to refer my local library WITHOUT using the "GOPATH"
3. In my "main" files I have "import (. pkgname ...)" but this does not works.

Expectation:

my expectation was that the library "pkgname" after build is available in the global module cache (because pkg/.../pkgname.a was NOT written :-) but

"go list all" has NOT my package

Question: HOW do I refer to my local module-package from an existing executable ?

→thanks for help.

[Henry]

You need to tell go module where to find the library. It defaults to using central repositories (such as github). If you have the library in the local machine, you can add into your go.mod file something like this:

```

replace namespace/to/pkgname => local/path/to/pkgname

```

When you run 'go install', the resulting file is stored in the bin folder of your gopath.

[Igor Maznitsa]

in the case you should provide local path to your module through module.package replace => local.path in go.mod
it makes some pain and stops independent work with project. To decrease the pain, I made some solution for maven which automatically work with multi-module go projects (example), in the case modules are shared through local maven repository