On Wed, Jun 24, 2015 at 07:02:49PM +0200, Michał Górny wrote: > Dnia 2015-06-24, o godz. 11:51:44 > William Hubbs <[email protected]> napisał(a): > > > On Wed, Jun 24, 2015 at 05:54:31PM +0200, Michał Górny wrote: > > > Dnia 2015-06-24, o godz. 15:38:34 > > > "William Hubbs (williamh)" <[email protected]> napisał(a): > > > > *snip* > > > > > > # @FUNCTION: _golang-build_setup > > > > # @INTERNAL > > > > # @DESCRIPTION: > > > > # Make sure EGO_PN has a value. > > > > _golang-build_setup() { > > > > [ -z "${EGO_PN}" ] && > > > > > > Please don't use 'unsafe' single brackets. Use bash's double brackets, > > > i.e. [[ -z ${EGO_PN} ]]. > > > > Ok, this will be fixed. > > > > > > golang-build_src_compile() { > > > > debug-print-function ${FUNCNAME} "$@" > > > > > > > > _golang-build_setup > > > > set -- env > > > > GOPATH="${WORKDIR}/${P}:${EPREFIX}/usr/lib/go-gentoo" \ > > > > go build -v -work -x "${EGO_PN}" > > > > echo "$@" > > > > > > I suggest to push this to stderr, >&2. > > > > Why? this is just printing the command before we run it. Do Make, etc > > print this output to stderr? > > This is pretty much a debugging output which doesn't belong besides > regular output. Make doesn't, bash does.
My concern is, if the go tools themselves put some output on stdout and
some on stderr and I redirect everything to stderr, that could break
upstream behaviour, and I would rather not do that.
>
> > > > "$@" || die
> > >
> > > And anyway, this looks to have a common, repeating part that sounds
> > > like a good candidate for separate emake-like function... ego? :D
> >
> > Do you mean these lines:
> >
> > echo "$@"
> > "$@" || die
>
> Also the common settings for go.
>
> i.e.:
>
> set -- env GOPATH="${WORKDIR}/${P}:${EPREFIX}/usr/lib/go-gentoo" \
> go "${@}"
> echo "${@}"
> "${@}" || die...
I would have to think about that, because you are looking at different
subcommands (build, get, install), so I would need to see which flags
are really common to all of them.
William
signature.asc
Description: Digital signature
