Unclear error with Asset and RestoreAsset

[niko-dunixi]

I'm getting a strange error that I don't understand. I don't know what it means but it occurs during when I run astilectron-bundler -v.

DEBU[0000] Generating /Users/paul.baker/go/src/github.com/paul-nelson-baker/go-jira-rfc-report-generator/bind_darwin_amd64.go
DEBU[0002] Building for os darwin and arch amd64
DEBU[0002] Executing go build -ldflags -s -X "main.AppName=JIRA RFC Report Generator" -X "main.BuiltAt=2018-03-04 22:01:26.285963169 -0700 MST m=+2.248430856" -o /Users/paul.baker/go/src/github.com/paul-nelson-baker/go-jira-rfc-report-generator/output/darwin-amd64/binary github.com/paul-nelson-baker/go-jira-rfc-report-generator
FATA[0006] bundling failed: bundling for environment darwin/amd64 failed: building failed: # github.com/paul-nelson-baker/go-jira-rfc-report-generator
./main.go:14:2: Asset redeclared in this block
    previous declaration at ./bind_darwin_amd64.go:201:34
./main.go:15:2: RestoreAssets redeclared in this block
    previous declaration at ./bind_darwin_amd64.go:338:38
: exit status 2

I've basically done some random tinkering in an effort to understand what this means and I think I've isolated the meaningful code.

var (
    Asset         bootstrap.Asset
    RestoreAssets bootstrap.RestoreAssets
    AppName       string
    BuiltAt       string
    debug         = flag.Bool("d", false, "enables the debug mode")
    window        *astilectron.Window
)

func main() {
    flag.Parse()
    astilog.FlagInit()
    astilog.Debugf("Build: %s", BuiltAt)
        err := bootstrap.Run(bootstrap.Options{
        Asset:         Asset,
        RestoreAssets: RestoreAssets,
// rest omitted for sanity

If I go to my var section and comment out Asset and RestoreAssets, I introduce a compiler error HOWEVER the bundler succeeds to build the app as expected.

Am I not using the bundler correctly? Am I not writing my app the correct way? Is this a bug?

[niko-dunixi]

Actually I can re-create this by downloading the demo project and trying to run astilectron-bundler -v there too. I'm not sure if there's something wrong defined in my environment, since the demo does not have a compiler error because of the bind.go file included there, I'm assuming that either there is a bug or an environment issue but I have no idea what.

[asticode]

@paul-nelson-baker in the README of the demo, it mentions running the following command:

$ rm $GOPATH/src/github.com/asticode/go-astilectron-demo/bind.go

This file has to be there so that go get works when fetching the project but you have to remove it once it's done since the bundler creates a bind_os_arch.go file with the exact same function names that conflicts with bind.go.

Therefore, if you remove the bind.go file, your problems should be solved.

You can check out this issue for more information.

Does that fix your problem?

[niko-dunixi]

I think I understand now. The bundler doesn't use ld flags for Asset and RestoreAssets, like I thought it does with other things (like AppName and BuiltAt). The bind_<os>_<arch>.go files that are generated are full-filling that role by creating those functions we're passing. It only appeared to be a compiler error because the GoLand IDE can't provide insights to those file (mine are showing 180+MB and my IDE is configured for 4.19MB).

(For those that follow and need to see it but their IDE doesn't have enough memory, you can run ack -H "func (?:Restore)?Assets?\(" bind_*_*.go and see for yourself)

Thanks for explaining that, I hadn't found that issue before because it was closed.

[niko-dunixi]

@asticode Is there a particular reason these core functions aren't extrapolated to a separate/smaller unarchetect-specific file? I'm generating for osx/mac but these functions look the same, I don't know if it's the same on windows. A smaller file that the IDE can read could maybe prevent others from bothering you with this same issue over and over again.

I'd be willing to look into it in some of my spare time if that's something you're open to.

[niko-dunixi]

Ah, it's upstream in the bindata package... and that project's history seems... "complicated".

[asticode]

@paul-nelson-baker the functions have the same signature but the content changes that's why a separate bind file has to be generated for each os/arch

[niko-dunixi]

I'm referring to these bits here: toc.go and restore.go. You can see that the methods in question (Assset and RestoreAssets) are hard coded and don't have anything platform specific included in them. When I get some free time I'll see if what it would take to refactor them out so they're:

1. Not redundantly placed into each arch file.
2. Instead they're have them placed into a separate bind file (like your demo has) so GoLand doesn't throw a false negative.

[asticode]

@paul-nelson-baker I may have misunderstood what you're saying because I don't see why you want to do those changes.

The bind files are generated for each and every os/arch couples since their content will be different. Indeed they contain the electron and astilectron .zip files which are different based on the os/arch couple. And as each bind file will be around 50MB, it's not a good idea to commit it as far as I'm concerned.

That's why, instead, I decided to commit a bind.go file containing the necessary methods so that go get works.

In what way your changes will fix that?