Tag to use to compile the code in lambda

[dlsniper]

Hi,

First of all, thank you for open-sourcing this, it's really nice of you. Second, I'm not sure if I've got this right so I'd rather ask. Should I use // +build proxy in the files I need them to be in the lambda only? Thanks a lot.

[lion3ls]

Hi @dlsniper,

Thanks for your support, it's always great to see people using our project and enjoying it :).

About your question, nope, you don't have to set any comment like // +build proxy in your code. Just follow the steps as explained here in the wiki and everything should work.

Have I replied to your question?

PS: Visit us on Gitter to discuss about further hacking help 👍

[dlsniper]

@lsuss thanks for the fast reply. Sort of. The thing is that I'm looking at a project which can run in Lambda but can target other environments as well and since I can abstract away all the input sources I would have something like:

code.go
project_lambda.go
project_ec2.go
project_pi.go

The _lambda go contains the lambda specific bits, _ec2.go the ec2 ones and _pi.go the pi ones. Since all of these would be containing a main() function then it would be interesting to know how to compile a project like this.

I could structure it like this as well:

code.go
cmd/lambda/project.go
cmd/ec2/project.go
cmd/pi/project.go

But I haven't checked if this works or not.

[cristim]

@dlsniper I have a project that runs in Lambda with this library compiled with that Docker image, but can also be compiled as a stand-alone binary using go build, for local execution.

You can only have a single main, but you can split the rest of the code in multiple files, and have them built on a per-target basis using build flags, as long as they are interchangeable, they just need to implement the same function that gets called from main.

[fsenart]

Hi @dlsniper,

Historically this project was done for Linux guys. You needed to install Python development libraries along with GCC stuff, and you was able to build your Lambda from the CLI without even using Docker. But, immediately after the release, OSX guys come, and we needed to provide a Docker image with these dependencies installed. All things worked as expected for building your Lambda but there was a problem for unit testing your Lambda locally without needing any Docker, nor Python, etc. dependencies (see #9). Then, we decided to separate CGO and GO parts and use build tags to:

• exclude CGO stuff for local unit tests
• include CGO stuff when building the final Lambda inside the Docker image.

This is why you see // +build proxy in CGO parts of this project. You, as an end user, should not care about this build tag, as this is only used internally by the Docker entry point to build your Lambda. You write regular Go, without any further build tag and use the standard build command docker run --rm -v $GOPATH:/go -v $PWD:/tmp eawsy/aws-lambda-go to build and package your Lambda.

As @cristim said, you can still use build tags to include/exclude some parts of your project for target based builds, as long as these build tags do not collide with the one we are using, i.e. // +build proxy.

[dlsniper]

I'm sorry, it's still unclear. How can I compile a project that uses both this to target the lambda and a normal server?

[cristim]

@dlsniper have a look at how I did it here: https://github.com/cristim/autospotting/blob/master/autospotting.go

In your case you may want to have multiple run() functions, one for each target platform, and stored in different files, built depending on build flags.

Update: the init() runs both when called from Lambda, but also when executed locally.

[fsenart]

@dlsniper, let's take a scenario.

We have 3 files; two target dependent and one common.

• lambda.go This file will have all stuff needed to bootstrap a Lambda like this project, etc.

  // +build lambda
  // ...

• ec2.go This file will have all stuff needed to bootstrap an EC2, etc.

  // +build ec2
  // ...

• common.go This file will have common stuff used by the target dependent parts.

  // NO BUILD TAGS HERE
  // ...

As build tags are inclusive:

• File without any build tag is included in the build
• File with the proper build tag is included in the build
• File without the proper build tag isn't included in the build

So how to build for specific targets now:

• Lambda: go build -buildmode=c-shared -ldflags="-w -s" -tags "proxy lambda" -o handler.so For now you can't pass custom build tags to the docker entrypoint.
• EC2: go build -tags ec2 You use the custom ec2 build tag to exclude Lambda stuff, include ec2 stuff and common stuff.

UPDATE: I've finally understood your problem :) and updated my answer in accordance.

[fsenart]

@dlsniper If you agree, we should change the issue title to something like "Pass custom build tags to the Docker entrypoint".

[dlsniper]

@fsenart sorry, I had to be away from the Internet for a while. Yes, that would definitely be fine, I apologize for the delay and not being more clear about the question. Thank you so much for your time and help.

[fsenart]

@dlsniper apologize too for the delay :) We were very busy past days. We are about releasing a brand new version of the project. It leverages Go 1.8 plugins. Then this issue won't be one, as you'll be free to use any tags you need and compile your code with any option you need to give to the Go compiler. So please little more patience, you won't be disappointed.

[dlsniper]

@fsenart please don't apologize, I've been terribly busy as well. Thank you so much for your hard work on this project!

[fsenart]

@dlsniper here is the new version of Go support for AWS Lambda. This new version resolves your issue de facto. https://github.com/eawsy/aws-lambda-go-shim