Development vs Production Environments (replacements for #ifdef DEBUG)

[Douglas Mayle]

I'm looking at how to create a section of code that works differently depending on BUILD type.  One example of a problem that I'd like to solve:

I have internal resources, and I want the binary to use different versions whether I'm developing, or in production (e.g. serving minified JS resources vs the uncompressed debuggable version).

I could just add a flag to specify the difference between the two, but the serving model is different between the two (paths change, files can be combined, etc.).

I've done some searching, and it looks like the suggestions given were to use your build system to conditionally change packages.  What's not clear to me is: Should I be writing two different packages with identical APIs, and use the build system to load one or the other into the same package name?  Is there a way to attempt importing of a package, and not use it if it isn't part of the binary?

Thanks,

Doug

[roger peppe]

you might find that the build rules outline here
are useful:
http://golang.org/pkg/go/build/

[Albert Strasheim]

Hello

On Thursday, July 12, 2012 6:37:18 PM UTC+2, Douglas Mayle wrote:

I'm looking at how to create a section of code that works differently depending on BUILD type.  One example of a problem that I'd like to solve:

I have internal resources, and I want the binary to use different versions whether I'm developing, or in production (e.g. serving minified JS resources vs the uncompressed debuggable version).

I could just add a flag to specify the difference between the two, but the serving model is different between the two (paths change, files can be combined, etc.).

You might consider adding a top-level Makefile or script to your project that does either GOPATH=/path/to/common:/path/to/debug or GOPATH=/path/to/common:/path/to/release and organise your source accordingly.

debug and release could have the same package structure inside.

Cheers

Albert

[Kyle Lemons]

To be more concrete:

file_prod.go:

// +build !devel

file_debug.go

// +build devel

shuld allow you to use "go build" and "go build -tags devel" to control which mode you were in.

[Douglas Mayle]

Thanks, everyone, that's exactly what I was looking for...  In my case, I'm using the tag 'prod', and defaulting to development builds, since I build for development much more often.

Cheers,

Doug

[Miki Tebeka]

I would encourage you to that with configuration and not in build flags. This way the code you're testing is exactly the one going to production.

Just my 2c...

[Douglas Mayle]

Just a quick note to others running across this thread, there needs to be a blank line in between your build constraints comment, and the rest of the file or the build system will ignore the build constraint (the '// +build ...')

Cheers,

Doug