add support for golang

[ignatenkobrain]

Basic test: https://github.com/ignatenkobrain/meson/commit/12ebc12bd9fa1b9c7a9b87ddc05b07bbb499aa36

There are 2 options for compilers:

• gcc-go (/usr/bin/gccgo)
• go (/usr/bin/go build)

I think we should prefer gcc-go over go.

[jpakkane]

I'm not a Go expert but as far as I know plain go is the reference implementation and more used of the two. That means we probably need to support that at least as well as gccgo.

[ignatenkobrain]

In fedora we are building all go packages via gccgo

[ignatenkobrain]

But yes, we should support plain go also. I think it should be used if gccgo not found.

[vit1251]

I was try compile go example with meson right now and receive follow error:

meson builddir
The Meson build system
Version: 0.46.0
Source dir: /root/Work/go-example/hello-example
Build dir: /root/Work/go-example/hello-example/builddir
Build type: native build
Project name: hello

meson.build:1:0: ERROR:  Tried to use unknown language "go".

Could you please clarify how to compile go application.

P.S. Most popular problem in GO is GOPATH environment variable. May meson resolve this problem?

[martingkelly]

Did this ever Go anywhere? (pardon the pun :) )

[nirbheek]

Did this ever Go anywhere? (pardon the pun :) )

Well, no one ever volunteered to work on it, so it can't go anywhere till that happens.

[martingkelly]

I figured; just wanted to check. Thanks for the update.

[treyzania]

@vit1251 Theoretically Meson could just use a per-project GOPATH that would help avoid some of the strange idiosyncrasies Go has.

Using gccgo would make interop with C much easier. It's also mentioned here that gccgo follows the Go spec (as "the go compiler" isn't the reference implementation), and it's written by the same dev team anyways. It would also integrate with Meson better. The problem is that it looks like the libgo in gccgo only supports POSIX systems, so cross-platform support is lacking at the moment. (Although in my book that's perfectly fine! :wink:)

[vit1251]

@treyzania resolve GOPATH problem right now require a lot of effort to search on machine and keep path update or hacking source in multi-module project. Right now I feel using go a painful solution but very high power of language and wide modules space is well.

I not well know meson inside but understand that most classic platform support by golang inside and a know that go have crosscompile option.

[oct2pus]

with the introduction of go.mod $GOPATH shouldn't need to be resolved anymore, unless I misunderstand how go.mod works.

[tinyzimmer]

It's probably worth posting here that I'm at least playing with the idea of writing the support for this. I got about 20% of the way there (basically getting meson to recognize it as a compiler option), but I am still on the fence on if I have the will power to go all the way with it.

Perhaps if I get it to at least a semi-functional I'll open a WIP PR, and maybe lean on yall for some guidance in different areas.

[gizahNL]

It's probably worth posting here that I'm at least playing with the idea of writing the support for this. I got about 20% of the way there (basically getting meson to recognize it as a compiler option), but I am still on the fence on if I have the will power to go all the way with it.

Perhaps if I get it to at least a semi-functional I'll open a WIP PR, and maybe lean on yall for some guidance in different areas.

Did you manage to advance this? I'm working on a go project that would need building a CPP wrapper and ideally also handle C library dependencies (finding them, building as subproject when not available etc.), so it would benefit greatly from meson support

[gizahNL]

As a hack, for whomever is interested this is what I use now to build my application:

golang = find_program('go')
streamzeug_path = join_paths(meson.current_source_dir(), 'cmd/streamzeug/')
streamzeug_env = environment()
streamzeug_env.set('LIBRARY_PATH', meson.current_build_dir())
r = run_command('streamzeug_files.sh', meson.current_source_dir())
streamzeug_files = r.stdout().strip().split()
streamzeug_files += 'go.mod'
streamzeug_files += 'go.sum'
streamzeug_build_path = join_paths(meson.current_source_dir(), 'cmd/streamzeug')

streamzeug = custom_target(
    'streamzeug',
    output: 'streamzeug',
    env: streamzeug_env,
    input: streamzeug_files,
    command: [ golang, 'build', '-o','@OUTPUT@', streamzeug_build_path],
    install: true,
    install_dir: 'bin',
    depends: libdektecasi,
    install: true,
)

Unfortunately golang doesn't detect changes in libraries it links against, so in those cases so then "go build -a" is needed to invalidate any caching.

The files script is simply cd $1 && find . -name '*.go'

[dontlaugh]

I'm new to Meson, but I write a lot of Go. Let's not give up on this! The Go ecosystem is plagued by Makefiles. Even having first class support and a little bit of structure around building (and cross-compiling) multiple executables from a single repository (extremely common) would be a win. This is the case even if CGO isn't involved.

[eli-schwartz]

Let's not give up on this!

The ticket is still open -- no one ever submitted a PR or a design document on how it should work.

Are you volunteering? :) If so, great!

[dcbaker]

@dontlaugh If you're interested and stuck I've added support for one language, and done a bunch of work on two more. I'm happy to answer questions :)

[dontlaugh]

@dcbaker I am interested in talking about it. Are you on IRC? Or should I ask questions here

[tristan957]

@dontlaugh he is on Matrix/IRC in #mesonbuild. Feel free to stop by. People are generally responsive

[eli-schwartz]

Yes he is.

As a general rule of thumb the entire core team is available on IRC -- #mesonbuild on the OFTC network. (Most, but not all, are constantly connected.) :)

[dcbaker]

@dontlaugh yes, same nick. I'm constantly connected, so if I don't get back to you right away when you mention me I will get back to you

[nirbheek]

The IRC network is OFTC, and the matrix joining link is: https://matrix.to/#/#mesonbuild:matrix.org

[gizahNL]

@dcbaker I am interested in talking about it. Are you on IRC? Or should I ask questions here Did you ever manage to get any results going?

I'm very interested in seeing Golang support working. If you need some inspiration look at https://github.com/odmanaged/streamzeug which is a mixed Golang/C++/C project I hacked together via meson. Would love to see a better & supported way for it!

[tristan957]

Are you going to pay someone or contribute it yourself? :)

I don't mean to sound like a negative nancy, but we all definitely want Go support. It is just is someone gonna put in the leg work? For the past few years the answer has been no, and will most likely stay no until a corporate interest wants it or someone else is motivated enough to do it.

Go is really not a great language due to the specifics of how the compiler works with regard to source layout and how dependency fetching works. It all needs to be given thought. structured_sources() is a step in the right direction for supporting Go.

[gizahNL]

Are you going to pay someone or contribute it yourself? :)

I don't mean to sound like a negative nancy, but we all definitely want Go support. It is just is someone gonna put in the leg work? For the past few years the answer has been no, and will most likely stay no until a corporate interest wants it or someone else is motivated enough to do it.

Don't worry about coming over negative ;) I do open source. I know it ;)

Likely I won't have time myself (and my Python fu is not that awesome); I'll pitch it though to see if my employer would be interested in funding.

[tristan957]

I am also interested in it since I have some Go language bindings sitting around, but I have not been motivated enough to touch this. I just wrap the go compiler in a custom_target() and call it a day.

[gizahNL]

If you know someone capable and willing to do it for funding, or fit the description yourself we can figure out what's possible ;)

My employer is willing to invest :)

[tristan957]

I would talk to @jpakkane. He does contracting work, so he could be the person you are looking for. Otherwise the other maintainers of this project are the people you should talk to. I am probably not the person you are looking for. I am a very minor contributor.

[dontlaugh]

I have started a #mesonbuild channel in the Gopher Slack (the big one). IRC is where meson devs hang out, but there are many competent C/C++ programmers in the Go Slack, who might have input.