Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow templating for env vars within build, and build overrides #3580

Closed
2 tasks done
HenryNguyen5 opened this issue Nov 22, 2022 · 4 comments · Fixed by #3592
Closed
2 tasks done

Allow templating for env vars within build, and build overrides #3580

HenryNguyen5 opened this issue Nov 22, 2022 · 4 comments · Fixed by #3592
Assignees
Labels
enhancement New feature or request

Comments

@HenryNguyen5
Copy link

Is your feature request related to a problem? Please describe.

Currently, im using cross-platform builds via zig, for an example you can see: https://dev.to/kristoff/zig-makes-go-cross-compilation-just-work-29ho

What ends up happening is that I have a very long CC and CXX env var that gets mostly reused across builds, but with minor changes per platform.

Ex. This is what my build script looks like right now:

macos_compiler_flags=" \
-isysroot$sdk_dir \
-F$sdk_dir$framework_search_path \
-iframeworkwithsysroot$framework_search_path \
-iwithsysroot$include_search_path \
-mmacosx-version-min=11.7.1"

main_ld_flags="-s -w -X 'main.Version=${VERSION-}'"

# We set system-dependent relative paths here so we can store the lib within ./libs
# https://dev.my-gate.net/2021/08/04/understanding-rpath-with-cmake/
mac_ld_flags="$main_ld_flags -r=@executable_path/libs"
linux_ld_flags="$main_ld_flags -r=\$ORIGIN/libs"

build_flags=(-trimpath -buildmode=pie)
cc="zig cc -target"
cxx="zig c++ -target"

export CGO_ENABLED=1

mkdir -p ./dist

export GOOS=darwin
GOARCH=arm64 \
  CC="$cc aarch64-macos $macos_compiler_flags" \
  CCX="$cxx aarch64-macos $macos_compiler_flags" \
  go build "${build_flags[@]}" -ldflags="$mac_ld_flags" -o dist/myprogram-macos-m1 ./cmd

GOARCH=amd64 \
  CC="$cc x86_64-macos $macos_compiler_flags" \
  CCX="$cxx x86_64-macos $macos_compiler_flags" \
  go build "${build_flags[@]}" -ldflags="$mac_ld_flags" -o dist/myprogram-macos-x86_64 ./cmd

export GOOS=linux
GOARCH=arm64 \
  CC="$cc aarch64-linux-gnu" \
  CCX="$cxx aarch64-linux-gnu" \
  go build "${build_flags[@]}" -ldflags="$linux_ld_flags" -o dist/myprogram-linux-aarch64 ./cmd

GOARCH=amd64 \
  CC="$cc x86_64-linux-gnu" \
  CCX="$cxx x86_64-linux-gnu" \
  go build "${build_flags[@]}" -ldflags="$linux_ld_flags" -o dist/myprogram-linux-x86_64 ./cmd

I previously found #2829 (comment) which states that it might not be possible, but it was awhile ago, so maybe that situation is better now.

Describe the solution you'd like

It would be nice to be able to write something like the following:

builds:
  - main: ./cmd
    ldflags: -X "main.Version={{ .Version }}"
    id: mac
    env:
      - CC=zig cc -v -target {{ if eq .Arch "arm64" }}aarch64{{else}}x86_64{{end}}-macos
      - CCX=zig c++ -v  -target {{ if eq .Arch "arm64" }}aarch64{{else}}x86_64{{end}}-macos
    goarch:
      - arm64
      - amd64
    flags:
      - -trimpath
      - -buildmode=pie
    goos:
      - darwin

or/and be able to do the same with env fields within overrides.

Another possible solution would be to expose CC and CXX as their own specific fields like ldflags which supports templating, since they are frequently used for cross platform builds with CGO enabled.

Describe alternatives you've considered

I considered this: #459

But with the amount of flags i am maintaining for CXX and CC, it would result in a lot of duplication, and I am better off just using shell scripts instead which let me compose the env vars.

Search

  • I did search for other open and closed issues before opening this.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Additional context

No response

@HenryNguyen5 HenryNguyen5 added enhancement New feature or request triage Issue pending triage by one of the maintainers labels Nov 22, 2022
@caarlos0
Copy link
Member

refs #2583

@caarlos0
Copy link
Member

I don't remember why the hooks were a problem for #2583, will have to re-investigate.

caarlos0 added a commit that referenced this issue Nov 24, 2022
closes #3580
refs #2583

Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
caarlos0 added a commit that referenced this issue Nov 24, 2022
closes #3580
refs #2583

Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
@caarlos0
Copy link
Member

hey @HenryNguyen5 , could you give #3592 a try?

caarlos0 added a commit that referenced this issue Nov 25, 2022
GoReleaser evolved a lot since the last time I tried to implement this
>1 year ago.
Now its 100% possible, and way simpler to do it!

closes #3580
refs #2583

Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
@caarlos0 caarlos0 removed the triage Issue pending triage by one of the maintainers label Nov 25, 2022
@HenryNguyen5
Copy link
Author

hey @HenryNguyen5 , could you give #3592 a try?

hey @caarlos0! sorry for the late reply. I'd like to confirm that it looks like it's working with the testing I've been doing so far. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants