1.0.0.alpha#164 Cannot Run Go Application configuration

[jtseatwave]

*** I removed the full paths from screenshots and output below ***
I am unable to run the go application. I can run go build from the project directory and it creates a go executable. However I get the below output from the run command. It appears that the plugin is only building the main source file and not the whole directory

# command-line-arguments
# command-line-arguments
.../run_imports.go:14: undefined: VerifyVenueAddresses
.../run_imports.go:18: undefined: Importer
.../run_imports.go:20: undefined: Importer
.../run_imports.go:22: undefined: StartImport
.../run_imports.go:23: undefined: StartImport
.../run_imports.go:24: undefined: StartImport
.../run_imports.go:29: undefined: Importer
.../run_imports.go:32: undefined: WriteImports
.../run_imports.go:37: undefined: Importer```

[dlsniper]

Please select the full path to the file not the relative path.

[jtseatwave]

I just removed the full path to hide the project name.

[zolotov]

I can run go build from the project directory and it creates a go executable

What happens if you run go build run_imports.go in console?

[jtseatwave]

go build run_imports.go
# command-line-arguments
./run_imports.go:14: undefined: VerifyVenueAddresses
./run_imports.go:18: undefined: Importer
./run_imports.go:20: undefined: Importer
./run_imports.go:22: undefined: StartImport
./run_imports.go:23: undefined: StartImport
./run_imports.go:24: undefined: StartImport
./run_imports.go:29: undefined: Importer
./run_imports.go:32: undefined: WriteImports
./run_imports.go:37: undefined: Importer

[zolotov]

And what if you run go build -i run_imports.go?

[jtseatwave]

same output

[zolotov]

Ok, thank you. And the last one: go build -n. Just want to know what exactly go build does if there are no any parameter.

[jtseatwave]

go build -n .

#
# [directory]/catalogue-import/couchbase
#

mkdir -p $WORK/[directory]/catalogue-import/couchbase/_obj/
mkdir -p $WORK/[directory]/catalogue-import/
cd /Users/jt/go/src/[directory]/catalogue-import/couchbase
/usr/local/go/pkg/tool/darwin_amd64/6g -o $WORK/[directory]/catalogue-import/couchbase.a -trimpath $WORK -p [directory]/catalogue-import/couchbase -complete -D _/Users/jt/go/src/[directory]/catalogue-import/couchbase -I $WORK -I /Users/jt/go/pkg/darwin_amd64 -pack ./couchbase.go ./writer.go

#
# [directory]/catalogue-import/address
#

mkdir -p $WORK/[directory]/catalogue-import/address/_obj/
cd /Users/jt/go/src/[directory]/catalogue-import/address
/usr/local/go/pkg/tool/darwin_amd64/6g -o $WORK/[directory]/catalogue-import/address.a -trimpath $WORK -p [directory]/catalogue-import/address -complete -D _/Users/jt/go/src/[directory]/catalogue-import/address -I $WORK -I /Users/jt/go/pkg/darwin_amd64 -pack ./address_lookup.go ./main.go ./map_lookup.go

#
# [directory]/catalogue-import
#

mkdir -p $WORK/[directory]/catalogue-import/_obj/
mkdir -p $WORK/[directory]/catalogue-import/_obj/exe/
cd /Users/jt/go/src/[directory]/catalogue-import
/usr/local/go/pkg/tool/darwin_amd64/6g -o $WORK/[directory]/catalogue-import.a -trimpath $WORK -p [directory]/catalogue-import -complete -D _/Users/jt/go/src/[directory]/catalogue-import -I $WORK -I /Users/jt/go/pkg/darwin_amd64 -pack ./importer.go ./pa.go ./paftp.go ./run_address_verification.go ./run_imports.go ./sw.go ./tm.go
cd .
/usr/local/go/pkg/tool/darwin_amd64/6l -o $WORK/[directory]/catalogue-import/_obj/exe/a.out -L $WORK -L /Users/jt/go/pkg/darwin_amd64 -extld=clang $WORK/[directory]/catalogue-import.a
mv $WORK/[directory]/catalogue-import/_obj/exe/a.out catalogue-import

[zolotov]

Ok, thank you. Will try to figure out how to implement building on packages

[jtseatwave]

Thank you

[ccustine]

@zolotov Just a couple of things to point out here that will surely come up 5 seconds after you release application run configuration :-) The somewhat popular technique/hack for getting multiple executables from a single project will be a bit challenging, but I think there will be high demand.

myapp/
  main.go
  - commands/
      - cmd1/
          main.go
      - cmd2/
          main.go

This produces myapp, cmd1, and cmd2 executables when you go install ./... so the assumption of package main having main() as the only application executable will limit this type of project configuration. I think the default package main, main() will do for now but the extended use case would be very cool to have eventually.

FWIW, I was kind of picturing something like the Java Application run config where you select a module and pick from a list of scanned main() functions. I think this could possibly cover both file based as well as application run configs with a little forethought. I'm happy to help work through this with you guys.

[dlsniper]

@zolotov I think this can be closed as the plugin supports building packages now (it still misses multiple files/directory but the ticket is not about that).