Short of it is in the title... I'm trying to have the headerfile that cgo already creates cgo_export.h - but sticks in the working directory - created in a static location that I can reliably access (as working directories can and should change). Directly using cgo provides for a -headerfile option, but I see no such option within the build options of go build, nor a way of passing options to cgo from go build.
Besides using a second run of cgo(or some script to grab the header each time from the working directory) is there any way to produce the header file with go build
Related
I am trying to make a Taskfile.yml file for building go application, but I can't quite understand the need of "GOFLAGS=-mod=mod" command before go build main.go.
reference: https://dev.to/aurelievache/learning-go-by-examples-part-3-create-a-cli-app-in-go-1h43
So there are two things here
GOFLAGS
this is nothing but an environment variable(if you don't understand what an environment variable is, think of it like a value that can be accessed by any process in your current environment. These values are maintained by the OS).
So this GOFLAGS variable has a space separated list of flags that will automatically be passed to the appropriate go commands.
The flag we are setting here is mod, this flag is applicable to the go build command and may not be applicable to other go commands.
If you are curious how go does this, refer to this change request
Since we are mentioning this as part of the command, this environment variable is temporarily set and is not actually exported.
what does setting -mod=mod flag, actually do during go build?
The -mod flag controls whether go.mod may be automatically updated and whether the vendor directory is used.
-mod=mod tells the go command to ignore the vendor directory and to automatically update go.mod, for example, when an imported package is not provided by any known module.
Refer this.
Therefore
GOFLAGS="-mod=mod" go build main.go
is equivalent to
go build -mod=mod main.go
I am using the primary GO extension.
I use VS code a lot, now I'm learning GO lang.
And when I open VS Code every time I'm getting this:
Error loading workspace: found module "main.go" twice in the workspace.
While running the code it's giving the right output.
I don't know how to fix this.
Anybody, help me with this error.
It would be better to open in VSCode only one folder with its own go.mod project.
A workspace with multiple go.mod/project should be supported with 1.18
The go command now supports a "Workspace" mode.
If a go.work file is found in the working directory or a parent directory, or one is specified using the -workfile flag, it will put the go command into workspace mode.
In workspace mode, the go.work file will be used to determine the set of main modules used as the roots for module resolution, instead of using the normally-found go.mod file to specify the single main module.
As described in "How to make VScode Go work in a Multi-Module Repo" from Varun Kumar, this used to work:
If you want to work with all the nested modules in a single workspace, there is an opt-in module feature that allows to work with multiple modules without creating workspace folders for each module. Set this in your settings -
"build.experimentalWorkspaceModule": true
But as per september 2022 is deprecated.
See more at gopls documentation "Setting up your workspace".
I'm new to golang. I'm currently trying to use the godror driver to read from an Oracle db. I ran go get github.com/godror/godror in my project's root directory and am importing the library like so:
_ "github.com/godror/godror"
But, I'm getting the error
cannot find package "." in:
/test_repo/vendor/github.com/godror/godror"
I believe my PATH is set up properly, as the "go" command properly returns the expected "Go is a tool for managing Go source code..." response.
I can't exactly replicate your issue nor have I seen such a weird error - but regardless, if you were following the current go modules pattern you wouldn't have this issue to begin with.
You shouldn't run go get anymore to download modules to use for your programs. Instead, in the root directory of every go project, you'll run go mod init [modulename], which will create a go.mod file for you. After running go mod tidy, it will download all the dependencies and generate a go.sum file containing the dependency hashes for you as well. Next, running go build will generate a binary that you can run. At this point, if you make changes to any source file(s), running go build every subsequent time afterwards will make a new, updated binary in the same directory.
My app is packaged as the following:
|-cmd/
|-cmd/application/ <- this contains the main.go and other files
|-internal/ <- contains internal dependencies
|-vendor/ <- contains third party libraries
And when running the following command from the root /:
go build cmd/application/*.go
It produces an executable that works fine. But when typing the following command from inside /cmd/application:
go build my_app_custom_name
I get the Syntax error: newline unexpected error, as if it wasn't a bash executable anymore.
With the help of the indication #Volker after using the flags -v and -x I figured out that I was naming the package "myapp" and not "main" as it should be. Now it works just fine.
As said by #Kaedys and #JimB, it is preferable to use the standard form for building apps :
go build // Method one from inside directory with go files
go build full/import/path/of/package/to/build // second method
Note that this is the recommended way in How to write Go code
The other way to build is using go build . and go build *.go in the directory where you go package is.
I am autotoolizing a library project, and this project has some example programs. I want the example programs to be distributed in the dist, but not installed.
Currently the demo programs are organized like thus:
src/*.cpp (library source)
include/*.h (library headers)
demos/demo.cpp (example program)
demos/RunDemo (script to run demo)
It is important that RunDemo be runnable after building the software, without requiring the "install" step.
So far I have been able to build the "demo" exectuable using a noinst_PROGRAMS target. However, after make in a VPATH build, the following is available:
build/src/.libs/libxxx.so (etc..)
build/demos/demo
As you can see, the RunDemo script needed to execute "demo" is not copied to the $(builddir). I have tried a few things, e.g., adding RunDemo to dist_noinst_SCRIPTS, as well as adding my own copy targets and trying to hook all.. no matter what I try, I always get the output,
$ make RunDemo
make: Nothing to be done for `../../../projects/demo/RunDemo'.
I seem to be unable to create a target in the builddir that says "if this file is not in the builddir, copy it from the srcdir."
Is this possible with automake?
You can make files accessible in the build tree after the ./configure step using the AC_CONFIG_LINKS macro (provided with autoconf) in your configure.ac script. It will create a symbolic link if possible, otherwise it will copy the file.
In your case it would look like
AC_CONFIG_LINKS([demos/RunDemo:demos/RunDemo])
From the autoconf manual:
Macro: AC_CONFIG_LINKS (dest:source..., [cmds], [init-cmds])
Make AC_OUTPUT link each of the existing files source to the
corresponding link name dest. Makes a symbolic link if possible,
otherwise a hard link if possible, otherwise a copy. The dest and
source names should be relative to the top level source or build
directory
Using dist_noinst_SCRIPTS is still necessary for the file to be distributed.