On Sat, Jul 04, 2015 at 12:43:37PM -0700, Zac Medico wrote: > On 07/04/2015 12:32 PM, William Hubbs wrote: > > On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote: > >> On 06/30/2015 03:08 PM, William Hubbs wrote: > >>> The source code is where the compatibility between versions of Go is, > >>> not the static objects, so what if, for third-party go packages, we > >>> skip installing the static objects? > >>> > >>> The only down side of this would be that there might be longer rebuilds > >>> if the packages have multiple consumers, but it gets rid of the static > >>> objects. > >>> > >>> What do you think? > >> > >> I'll give real example involving go-tools. The go-tools build requires > >> go-net, which in turn requires go-text. If the go-net *.a files are > >> installed, then it is possible to build go-tools against go-net without > >> having go-text installed. If the go-net *.a files are not installed, > >> then you will have to install go-text before you can build go-tools. It > >> introduces an indirect build-time dependency between go-tools and go-text. > > > > Sure, but what I'm proposing is that we do not install any *.a files > > for Go software that is not part of dev-lang/go. > > Exactly the same type of situation can arise for packages that are not > part of dev-lang/go. For example, if consul's static api.a library is > not installed, then it will introduce indirect build-time dependencies > for the consul-template package.
Hmm, I haven't looked at either consul or consul-template yet, but I'm thinking that if you use golang-build.eclass to install everything and make sure GOPATH is set correctly, consul-template will pick up everything it needs. What am I missing? William
signature.asc
Description: Digital signature
