-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Improve golang support #3386
Comments
The required dependencies are already checked into the git repository. This should also speed up the build. Not a complete solution to SynoCommunity#3386 but it should help.
The required dependencies are already checked into the git repository. This should also speed up the build. Not a complete solution to SynoCommunity#3386 but it should help.
The required dependencies are already checked into the git repository. This should also speed up the build. Not a complete solution to SynoCommunity#3386 but it should help.
* Do not update/recompile dependencies The required dependencies are already checked into the git repository. This should also speed up the build. Not a complete solution to #3386 but it should help. * Update dnscrypt-proxy to 2.0.17 * remove conf/resource It appears this file is not needed for help generation Also indexdb/helpindexdb and indexdb/appindexdb never existed * Use env instead of export * Use dns forwarding. fix bonjour devices. * Don't ask bind options on install, It is available in the config file * Update golang to 1.11.1 * Improve DSM support, using go's cgi lib Preserve owner and group id when saving file * Return full html after blacklist was generated. Fix where generating the blacklist would appear not have done anything. Note: previously using the browser reload button would overwrite the file with old content.
* Do not update/recompile dependencies The required dependencies are already checked into the git repository. This should also speed up the build. Not a complete solution to SynoCommunity#3386 but it should help. * Update dnscrypt-proxy to 2.0.17 * remove conf/resource It appears this file is not needed for help generation Also indexdb/helpindexdb and indexdb/appindexdb never existed * Use env instead of export * Use dns forwarding. fix bonjour devices. * Don't ask bind options on install, It is available in the config file * Update golang to 1.11.1 * Improve DSM support, using go's cgi lib Preserve owner and group id when saving file * Return full html after blacklist was generated. Fix where generating the blacklist would appear not have done anything. Note: previously using the browser reload button would overwrite the file with old content.
@publicarray with commit f79eb26 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. |
Because the cgi script for the web GUI is written in go. |
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:
So until now there is no module that does $ARCH dependent compilation in spk makefile. |
@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. 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... |
@ymartin59 I can't remember that "caveat to use $ARCH" so forget it. |
I will rework the dnscrypt-proxy package soon (now that I know how the framework actually works) |
Current support for golang has following drawbacks:
dep
each time for each archdep ensure
takes ages without progress bar - is it possible to re-use and prevents its run for each arch?The text was updated successfully, but these errors were encountered: