Leo Famulari writes:
> On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote:
>>
>> Ricardo Wurmus writes:
>>
>> > You could also access the arguments of another package with
>> > “package-arguments”. Using the “properties” field isn’t pretty
On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote:
>
> Ricardo Wurmus writes:
>
> > You could also access the arguments of another package with
> > “package-arguments”. Using the “properties” field isn’t pretty because
> > it is a free form alist.
> >
> > You
On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote:
>
> Ricardo Wurmus writes:
>
> > You could also access the arguments of another package with
> > “package-arguments”. Using the “properties” field isn’t pretty because
> > it is a free form alist.
> >
> > You
Maybe the following will help clarify the issue:
The package being built needs the sources of the dependenc(y/ies) to
be available in its GOPATH.
The build system needs to set the GOPATH such that the Go build system
will find the the dependencies and build against them.
I have a repository[1]
Ricardo Wurmus writes:
> You could also access the arguments of another package with
> “package-arguments”. Using the “properties” field isn’t pretty because
> it is a free form alist.
>
> You can use “find-tail” to jump to the keyword in “arguments” and then
> pick the
Leo Famulari writes:
> So, a Go build system needs to somehow create a symlink union of the
> dependency graph, making the dependencies available at the correct paths
> relative to the root of the build environment. AFAICT, we can't figure
> these paths out programatically;
Recently I made some progress on finishing the prototype go-build-system
from Petter [0], and I need some advice.
AFAICT, building a Go program requires the program's Go dependencies to
have a particular filesystem layout, which corresponds to the way these
dependencies are imported by the