In C, source files do not depend on other source files, they merely depend on
headers, eg:
foo.$O: foo.c foo.h bar.h
bar.$O: bar.c bar.h baz.h
baz.$O: baz.c baz.h
So, because the dependencies exist and do not depend on the outputs of other
commands, it's possible to build the obect files in any order. However, in
Go, the exported symbols (the equivalent of headers) are generated from source
and put into the libraries, meaning you end up with a dependency graph like
this:
foo.$O: foo.c bar.o
bar.$O: bar.c baz.o
baz.$O: baz.c
'mk' can handle that if you explicitly give the list of object files that a
source file depends on, but it has no good way of probing it automatically,
as a build progresses. making maintaining mkfiles tedious and error prone.
Effectively, it means that every time you change an import in Go, you would
have to modify the mkfile. 'go build' is able to determine the build order
needed automatically without the need to maintain an out-of-line dependency
graph that can get out of date.
At least in my understanding.
On Mon, 25 Mar 2013 10:43:44 +0100
dexen deVries <dexen.devr...@gmail.com> wrote:
> On Saturday 23 of March 2013 12:37:17 Rob Pike wrote:
> > (...) and because go install does
> > transitive dependencies correctly, which mk does not.
>
> anybody care to explain what is the limitation of mk here? can't wrap my head
> around it...
>
>
> --
> dexen deVries
>
> [[[↓][→]]]
>
>
--
Ori Bernstein <o...@eigenstate.org>
