goracle incompatible with gomods

[fedepaol]

If I try to use the new go 1.11 dependency management (go mods) I get the same
fatal error: dpiImpl.h: No such file or directory
error referenced in #80

The reason for this is that go modules do not vendor non package directories, and there is no workaround as per golang/go#26366

The suggested solution is to put all the files needed to build a package inside the package dir , which I guess means throwing all the .c / .h files in a package dir.

That is also referenced in the cgo documentation https://golang.org/cmd/cgo/ where it says "so all non-Go source code for the package should be stored in the package directory, not in subdirectories."

A possible workaround proposed in golang/go#26366 is to "package-ize" the c-sources folder in order to have it vendored by adding a dummy .go file and referencing the package as not used (with _ import).

[tgulacsi]

Or just forget the vendoring, and use it as a module - that works! Federico Paolinelli <notifications@github.com> ezt írta (időpont: 2018. szept. 27., Cs, 17:52):

…

If I try to use the new go 1.11 dependency management (go mods) I get the same fatal error: dpiImpl.h: No such file or directory error referenced in #80 <#80> The reason for this is that go modules do not vendor non package directories, and there is no workaround as per golang/go#26366 <golang/go#26366> The suggested solution is to *put all the files needed to build a package inside the package dir* , which I guess means throwing all the .c / .h files in a package dir. That is also referenced in the cgo documentation https://golang.org/cmd/cgo/ where it says "*so all non-Go source code for the package should be stored in the package directory, not in subdirectories.*" A possible workaround proposed in golang/go#26366 <golang/go#26366> is to "package-ize" the c-sources folder in order to have it vendored by adding a dummy .go file and referencing the package as not used (with _ import). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#104>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPoSlnS9ypmHGvDNb9-Y5jzSz2HA8XLks5ufPQmgaJpZM4W89eH> .

[fedepaol]

Not sure I understand what you mean. Could you elaborate? Il gio 27 set 2018, 19:15 Tamás Gulácsi <notifications@github.com> ha scritto:

…

Or just forget the vendoring, and use it as a module - that works! Federico Paolinelli ***@***.***> ezt írta (időpont: 2018. szept. 27., Cs, 17:52): > If I try to use the new go 1.11 dependency management (go mods) I get the > same > fatal error: dpiImpl.h: No such file or directory > error referenced in #80 <#80 > > > The reason for this is that go modules do not vendor non package > directories, and there is no workaround as per golang/go#26366 > <golang/go#26366> > > The suggested solution is to *put all the files needed to build a package > inside the package dir* , which I guess means throwing all the .c / .h > files in a package dir. > > That is also referenced in the cgo documentation > https://golang.org/cmd/cgo/ where it says "*so all non-Go source code for > the package should be stored in the package directory, not in > subdirectories.*" > > A possible workaround proposed in golang/go#26366 > <golang/go#26366> is to "package-ize" the > c-sources folder in order to have it vendored by adding a dummy .go file > and referencing the package as not used (with _ import). > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#104>, or mute the thread > < https://github.com/notifications/unsubscribe-auth/AAPoSlnS9ypmHGvDNb9-Y5jzSz2HA8XLks5ufPQmgaJpZM4W89eH > > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#104 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMPcOQBnes7__oj6JPPBmBcLZebCZUMks5ufQeygaJpZM4W89eH> .

[tgulacsi]

Use GO111MODULE=on and do not use "go mod vendor", just "go build".

BTW, I've added "dummy.go" into each subdirectory (v2.8.1), but go mod vendor still erases the subdirectories.

[fedepaol]

Thanks for your reply!
Not sure that would work (I mean just go building with GOMODULES enabled).

If I create a new project outside the gopath, something along the line of

package main

import (
    "fmt"
    _ "github.com/go-goracle/goracle" // db driver
    "github.com/jmoiron/sqlx"
)

func main() {
    fmt.Println("vim-go")
    sqlx.Connect("goracle", "prova")
}

and run go mod init github.com/fedepaol/samplegoracle and then go build what I get is

go: finding github.com/jmoiron/sqlx latest
# github.com/go-goracle/goracle
../../go/pkg/mod/github.com/go-goracle/goracle@v2.1.14+incompatible/conn.go:20:10: fatal error: dpiImpl.h: No such file or directory
 #include "dpiImpl.h"
          ^~~~~~~~~~~
compilation terminated.

[tgulacsi]

Where does goracle v2.1.14 coming from? The current version is v2.8.1 - add it with

go get gopkg.in/goracle.v2@v2.8.1

[fedepaol]

Interesting!
It looks like if I import the package using the github path github.com/go-goracle/goracle it fetches that broken version, whereas if I import from gopkg.in it imports the right (and working) one.

Sorry for the interruption, I will close the issue.
Thanks again for your help!

[fedepaol]

BTW, I've added "dummy.go" into each subdirectory (v2.8.1), but go mod vendor still erases the subdirectories.

It erases it because you also have to "use" the package, even with a _ import

[tgulacsi]

Doesn't work:

$ go install
odpi/dummy.go:4:2: C source files not allowed when not using cgo or SWIG: dpi.c
odpi/dummy.go:6:2: C source files not allowed when not using cgo or SWIG: dpiConn.c dpiContext.c dpiData.c dpiDebug.c dpiDeqOptions.c dpiEnqOptions.c dpiEnv.c dpiError.c dpiGen.c dpiGlobal.c dpiHandleList.c dpiHandlePool.c dpiLob.c dpiMsgProps.c dpiObject.c dpiObjectAttr.c dpiObjectType.c dpiOci.c dpiOracleType.c dpiPool.c dpiRowid.c dpiSodaColl.c dpiSodaCollCursor.c dpiSodaDb.c dpiSodaDoc.c dpiSodaDocCursor.c dpiStmt.c dpiSubscr.c dpiUtils.c dpiVar.c

as it wants to compile it without cgo...