Improve golang support

[ymartin59]

Current support for golang has following drawbacks:

• download same dep each time for each arch
• dep ensure takes ages without progress bar - is it possible to re-use and prevents its run for each arch?
• more support for dependencies has to be provided, to ease application compilation process. See #2533 for Gogs as example

===>  Compiling for dnscrypt-proxy
mkdir -p /spksrc/spk/dnscrypt-proxy/work-rtd1296-6.1/bin
curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  5110  100  5110    0     0    852      0  0:00:05  0:00:05 --:--:--  1140
ARCH = amd64
OS = linux
Will install into /spksrc/spk/dnscrypt-proxy/work-rtd1296-6.1/bin
Fetching https://github.com/golang/dep/releases/latest..
Release Tag = v0.4.1
Fetching https://github.com/golang/dep/releases/tag/v0.4.1..
Fetching https://github.com/golang/dep/releases/download/v0.4.1/dep-linux-amd64..
Setting executable permissions.
Moving executable to /spksrc/spk/dnscrypt-proxy/work-rtd1296-6.1/bin/dep
cd /spksrc/spk/dnscrypt-proxy/work-rtd1296-6.1/src/github.com/dnscrypt-proxy/dnscrypt-proxy-2.0.15 && dep ensure
Warning: the following project(s) have [[constraint]] stanzas in Gopkg.toml:

  ✗  github.com/agl/ed25519

However, these projects are not direct dependencies of the current project:
they are not imported in any .go files, nor are they in the 'required' list in
Gopkg.toml. Dep only applies [[constraint]] rules to direct dependencies, so
these rules will have no effect.

Either import/require packages from these projects so that they become direct
dependencies, or convert each [[constraint]] to an [[override]] to enforce rules
on these projects, if they happen to be transitive dependencies,

cd /spksrc/spk/dnscrypt-proxy/work-rtd1296-6.1/src/github.com/dnscrypt-proxy/dnscrypt-proxy-2.0.15/dnscrypt-proxy && go build -ldflags="-s -w"

[hgy59]

@publicarray with commit f79eb26f74ce66294c019ce256c5c3543e3a63e of #3649 I was wondering why the dnscrypt-proxy spk makefile (/spk/dnscrypt-proxy/Makefile) calls the go compiler. IMHO the compilation should be done only with the sources in cross builds (/cross/dnscrypt-proxy/Makefile) and the spk make steps only builds the spk form the staging folder of the dependent cross targets.

The other spk built from go sources (syncthing) is implemented as I expected, without compilation in the spk make step.

Any hint why dnscrypt-proxy needs to compile again in the spk make step would be appreciated.

[publicarray]

Because the cgi script for the web GUI is written in go.

[hgy59]

Is there any reason against the move of ui source (cgi scripts etc.) to it's own cross module (like /cross/dnscrypt-proxy-ui or /cross/dnscrypt-proxy-dsm-ui)?

As far as I can remember my first tries with synocommunity/spksrc, it goes with caveat to use $ARCH variable in spk Makefiles.

Result of a quick search in spk makefiles for the use of $ARCH:

• debian-chroot and gentoo-chroot: these are modules without any dependency to cross modules and without compilation
• python: $ARCH used for arch dependent parameters for wheels
• sabnzbd and synocli-net: $ARCH used for contitional installation
• lirc: $ARCH used for evaluation of older kernel versions
• chromaprint, comskip and tvheadend: $ARCH used to reuse libraries from ffmpeg spk

So until now there is no module that does $ARCH dependent compilation in spk makefile. And I suggest to avoid this. any remarks by @ymartin59 ?

[ymartin59]

@hgy59 I am not sure to understand. Any "cross" module is "$ARCH" specific because of invoked toolchain behind "compile" and "install" targets... So that are "spk" when depending on "cross" modules.

Considering "UI sources" which are arch independant, they are often included in "spk" because they are specific to each application package - and so never re-used. From my point of view, they should not be in "cross/" as there is no need for "cross-compilation" ...what "cross" means in fact.

Pure non-arch package can be designed without any "cross", like for instance "syno-magnet": https://github.com/SynoCommunity/spksrc/tree/master/spk/syno-magnet

So again, sorry but I have probably missed your point. What is specifically the "caveat to use $ARCH" you think of? And what would be your proposal to fix that caveat? For instance as a quick draft PR on a single package as PoC...

[hgy59]

@ymartin59 I can't remember that "caveat to use $ARCH" so forget it. The "UI sources" here are arch dependent and are crosscompiled, since they are written in go. The package dnscrypt-proxy is crosscompiled with go, so it is reasonable to crosscompile the (wizard)-UI too and therefore I propose to build a cross package for the UI.

[publicarray]

I will rework the dnscrypt-proxy package soon (now that I know how the framework actually works)