authn-server
authn-server copied to clipboard
Add the nocgo build flag to enable a build without sqlite3
See description from commit below, but also:
- I prefer to keep my Go builds pure Go if possible (various reasons, some here: https://dave.cheney.net/2016/01/18/cgo-is-not-go)
- In particular static CGO (i.e.
-extldflags 'static') are broken on Go 1.13 on archs I use - This is motivated by library use, but you may have people who prefer vanilla-but-pure-go builds and this would enable that
- This is zero impact on your existing builds since db.go and blob_store.go are marked
+build !nocgo. I suspect maintenance of the stubs will be non-onerous. - I have used the build flag
nocgoto build without needing sqlite3 which is your only CGO dependency, but I could usenosqlite3or similar if you prefer. We kind of need the double negative because I don't want the normal builds to need a special flag, which we can achieve if the normal files are annotated with negated flag!nocgo - If you are minded to accepted I can add a comment in readme somewhere noting how to use this and/or a makefile target.
This involves adding some stub files that panic if they are ever used on a nocgo build - i.e. one excluding sqlite3 but the default build will build with sqlite3 support using CGO.
CGO is great if you need it, but can cause various types of failures and complexities particularly on on-standard toolcahins. As a library user I if I do not use sqlite3 I would rather not pay the prices of using CGO.
In particular at the time of writing static CGO builds with go 1.13 do not work for me on musl-gcc or Arch Linux.
Signed-off-by: Silas Davis [email protected]
Coverage remained the same at 77.44% when pulling 3462d0f73883f1a0174c3a391c968de9efdea2a8 on silasdavis:nocgo into 824d57d083a5a8582670898d32a007bb71131ecb on keratin:master.
The double-negative tag of !nocgo is awkward. Wouldn't it be better to to switch around the logic to the tags cgo and !cgo?
Edit: never mind... Somehow the commentary on the double-negative didn't show for me when I wrote this comment.
I'll add a makefile target.
Would we prefer !nosqlite as a tag?
- more explicit about what support is being turned off (though perhaps less about why you would want to do that)
- if there is ever another cgo dependency we'll need another negated tag for that dep
i prefer nocgo. it describes the root cause, and does not create questions about nomysql, nopostgresql, and noredis.
I think about this one sometimes when I think about ARM builds. Do we have any particular requirements for SQLite? There is eg https://pkg.go.dev/modernc.org/sqlite offering a pure go driver, it might not be as performant but our SQL usage is really simplistic it might be enough.
Sqlite is a good option for simple installs but is not necessary when Redis and either Postgres or MySQL are available.