[Work in progress] Unstable gobuild module

[antonysigma]

Syntax:

# meson.build file at path/to/go.mod
project('demo', 'cpp')

# Provides hello_world_inc and hello_world_lib
subdir('cpp_backend')

gobuild = import('unstable-gobuild')

demo_exe = gobuild.project('demo',
    sources: 'main.go',
    tags: [
        'desktop',
        'production',
    ],
    include_directories: hello_world_inc,
    link_with: hello_world_lib,
    gomod_tidy: true,
)

test('Help message',
  demo_exe,
  args: ['--help'],
)

(Inspired by the Icestorm module and the Gnome module.) Given a meson.build file at the same directory as the go.mod file, search for the external program go. Run go mod tidy to resolve all 3rd party dependencies. Run go test ./... to capture test results (build_by_default=False). Run go build to output the statically linked executable file.

Provide a native: bool option to cross-compile the go app with CGO_ENABLED=1. Generate CGO_CFLAGS and CGO_LDFLAGS from the fields include_directories and link_with.

Return the (statically-linked) executable so that we can test it with meson target test().

[antonysigma]

@dcbaker Thank you for the guidance. I submitted a new commit. Kindly asking for more guidance on the host_machine.system() support from within the unstable module.

[antonysigma]

I found it easier to build an archive with go build -buildmode=c-archive then make a C entrypoint that would call back to an exported Go function (go build in meson.build, go exported functions, C entrypoint).

@odrling Sounds good. This c-archive trick may solve my issue having incompatible object files when we set -Db_lto CC=clang CC_FOR_TARGET=gcc. Could you please create another PR that defines:

gobuild = import('unstable-gobuild')
main_cli_lib = gobuild.static_library('main_cli.go')

main_exe = executable('main', 'main.cpp', 'main_cli.h',
  link_with: main_cli_lib)

The code highlighted below is how we implement gobuild.project(...). I suppose we can almost copy-and-paste the code to implement gobuild.static_library.

[antonysigma]

Hi @dcbaker ,

Help wanted to refactor a custom_target() to a execute() target, so that we can resolve/validate Go project's 3rd party dependencies. Please refer to the inline-comments below.

Appreciate it!

-Antony

[antonysigma]

How do I invoke a command at meson setup or ninja reconfigure step?

The commands go mod tidy is analogous to meson subproject update; and go mod verify analogous to meson subproject foreach "md5sum ...". So, I suppose this should not belong to custom_target().

[dcbaker]

Given that explanation it seems like it would be better for us to have a way to hook into meson subproject update for go mod tidy. Not sure what to do about the verify step. That might be better as a run_target, ala ninja go-verify or something?

[antonysigma]

Not sure what to do about the verify step. That might be better as a run_target, ala ninja go-verify or something?

Sounds good. the meson's downstream CustomTarget API complains that RunTarget is not a valid type for the depends argument. I will read the manual again to see what I did wrong.

Side question: does ninja all and ninja reconfigure recompute the warpDB checksums, and validate the contents against that of the warp file? I suppose Go's authors developed go mod verify to guard against subprojects tampering after download and zip/tarball extraction.

[antonysigma]

it seems like it would be better for us to have a way to hook into meson subproject update for go mod tidy.

I digress... I am afraid to open the can of worms by having Meson subproject to take control of go mod tidy. Go language and the authors (time and time again) prevented the use of out-of-tree subprojects folder.

Not even Yocto / Google git-repo tools can defeat the mechanism. For example, git-repo can create a symlink to fool the (Make) build system by creating symlinks

ln -s subprojects/go_dependencies/ src/gobuild-projects/pkg/

...but I recalled that Go's build tool made it impossible.

Another example of such philosophy is the embed.FS API to embed static assets, similar to what we do with C language's #embed directive. They also made symlinked folder, path to parent folder, relative path to sibling folders, absolute paths, etc, impossible.