> > This is for a single-exe release right? > A tiny bit more as you can have extra files along your bin, setup icon for menu launchers, define env variables, and for deb/rpm have pre/post script where you can install services or do more fun stuff. Msi support is definitely missing that last feature.
Any plan to have share lib support for multiple-tool releases? > A totally different story imho, it was not my initial goal. I really wanted to be able to share those software with non go world, and this is fulfilled, almost. Not the brightest way, a way that work. I don t have experience with c programming (which heavily uses that feature) and their deployment methods/difficulties on unix friendly platforms, as a result i have poor general knowledge and experience of those problems. (does windows support that feature too ? I don t even know that..) So basically nop. Also note that preparing SRPM, or DEBS (S stands for Source) are way different than their counter binary part i provided here. I also think that because of historical reasons, you d better go with a makefile, dep, rpm, aur heavily relies on it when it come to build the final executable on the final machine. (then, the q is, how to not have to maintain multiple makefile for the various target systems, and how to handle that for windows. No clue.) Now i look to that https://deferpanic.com/blog/linking-to-a-precompiled-go-lang-library/ or this http://blog.ralch.com/tutorial/golang-sharing-libraries/ I wonder if it is up to date ? Two questions i have reading this, does a pre compiled binary can include at runtime a pre compiled library ? Said differently, does the final exe requires to be compiled on the final system ? Or, can it be simply shipped as a pre compiled file and include only some symbols to the dependents libraries to be resolved JIT on the final system ? In both ways, compiling on the target system, or pushing only a binary with appropriate symbols, where will it look for this libraries on the system (PATH?) ? Thus, is this a per system/distrib responsibility, or is it a per language responsibility to define an host directory ? anyways, as you can see, i have more questions than answers on that topic, as of today, i m not on the page to achieve such job. Le lundi 25 juillet 2016 18:40:49 UTC+2, Tong Sun a écrit : > > Looks good, Thanks. > > This is for a single-exe release right? > > Any plan to have share lib support for multiple-tool releases? I.e., to > allow many small tools written in GO to use the same shared lib, instead of > each carrying the full set of Go libs. > > On Sunday, July 24, 2016 at 12:18:42 PM UTC-4, mhhcbon wrote: >> >> >> After some efforts and lots of reading, >> i finally have the cool release flow i was looking for my own usage and >> purpose. >> >> I sum it and share it here https://github.com/mh-cbon/go-github-release >> >> Initially i was looking for the good automated, re usable practices to >> release a go package, >> i have ended into a feature complete release flow to deliver my software >> as deb/rpm/msi installers. >> I have improved my ability to maintain a changelog, >> and reproduced functionality i used to know in other programming >> languages. >> While this is perfectible, i believe it s a nice start. >> >> I hope you ll enjoy it and find interest into it to to release your >> packages and software. >> >> ~~Happy coding! >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
