Hi everyone,
I would like to introduce go-compilers packages.
Intro:
- golang language is supported on primary and secondary architectures
- at the moment we have two compilers: golang and gcc-go
- on Fedora we have a partial support for debugging
- go-srpm-macros packages provides basic macros (go_arches,
golang_arches, gcc_go_arches, ...)
- f21, f22, f23, rawhide, el6 are supported. Fedora is primary, el6 is
almost 1:1 with fedora branches (e.g. etcd is not build in el6 yet)
Current state:
At the moment if a user wants to package a golang projects he follows
golang packaging guidelines draft [1]. Among other things, there is a
recommended form of the spec file. In a "Packaging library" example
there is a build section which shows how to create symlink and build
package via 'go build' command. In a "Build ID" and "Debuginfo"
information how to hack build to be able to extract debug info is described.
[1] https://fedoraproject.org/wiki/PackagingDrafts/Go
Problems:
1) for given architecture correct compiler has to be chosen (go_arches,
golang_arches, gcc_go_arches macros)
2) if debug info is provided, building has to be hacked (generate Build
ID for golang compiler)
3) go-srpm-macros is in minimal buildroot
To solve 1), the following is used at the moment:
# If go_arches not defined fall through to implicit golang archs
%if 0%{?go_arches:1}
ExclusiveArch: %{go_arches}
%else
ExclusiveArch: %{ix86} x86_64 %{arm}
%endif
# If gccgo_arches does not fit or is not defined fall through to golang
%if %{isgccgoarch}
BuildRequires: gcc-go >= %{gccgo_min_vers}
%else
BuildRequires: golang
%endif
To solve 2), the following is used at the moment:
# If gccgo_arches does not fit or is not defined fall through to golang
# gccco arches
%if %{isgccgoarch}
%if 0%{?gcc_go_build:1}
export GOCOMPILER='%{gcc_go_build}'
%else
echo "No compiler for SA"
exit 1
%endif
# golang arches (due to ExclusiveArch)
%else
%if 0%{?golang_build:1}
export GOCOMPILER='%{golang_build}'
%else
export GOCOMPILER='go build'
%endif
%endif
%if 0%{?with_debug} && !%{isgccgoarch}
function gobuild {
local LDFLAGS="-B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \n')"
eval ${GOCOMPILER} -a -v -x "$@";
}
%else
function gobuild { eval ${GOCOMPILER} -a -v -x "$@"; }
%endif
Why so long? Intention was to cover situations where there is no
go-srpm-macros package (rhel, possibly f21) in a minimal buildroot.
- the first block sets GOCOMPILER env and choose the correct compiler.
- the second block defines gobuild function which for a case of golang
compiler generates Build ID for resulting binary.
What is go-compilers package?
- review request: https://bugzilla.redhat.com/show_bug.cgi?id=1258182
- it consists of two packages (one that requires golang compiler, one
that requires gcc-go compiler)
- based on an architecture it provides three virtual provides:
compiler(go-compiler), compiler(golang), compiler (gcc-go)
- based on an architecture it defines gobuild and gotest macros which
hide hack for Build ID for golang compiler (transparent to user) and
hides golang/gcc-go compiler command (thus making one command for all
compilers the same)
How go-compilers solves problems 1-3)
- Make 1) shorter. With go-compilers it is possible to just use
ExclusiveArch: %{go_arches}
BuildRequires: compiler(go-compiler)
- Make 2) shorter. go-compilers ships macros.go-compilers which defines
%{gobuild} and %{gotest} macros for golang or gcc-go based on
architectures. Both blocks can be removed. How is gobuild defined?
%gobuild() \
function gobuild { \
local LDFLAGS="${LDFLAGS:-} -B 0x$(head -c20 /dev/urandom|od -An -tx1|tr
-d ' \\n')" \
go build -compiler gc -ldflags "${LDFLAGS:-}" -a -v -x "$@"; \
} \
gobuild %{?*}
- For 3) go-srpm-macros will be provided by go-compilers subpackages.
Besides, go-srpm-macros in not in epel6 at the moment. This way, it will
be there.
Why it could be improved?
a) Make choose of compiler transparent for user. And change the compiler
for all packages at once.
b) Make Build ID hack transparent for user. Move it to one place so it
can be updated in one place only if needed.
c) Make the spec file as short as possible. User can always decide if he
uses %{gobuild} macro or not.
What do you think? Is it worth creating the package? Will it simplify
packaging or not? My aim is to hide all compiler specific features and
provide abstract functions as a black box. Those functions can be then
changed independent of user's spec file. For example, when golang
compiler starts to generate build id's, the generator can be removed
without changing user's spec file.
Any suggestions or feedback is appreciated and welcome.
Regards
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
