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
[[[↓][→]]]
anybody care to explain what is the limitation of mk here? can't wrap my head
around it...
It only knows about the rules you give it. It does not understand the real
dependencies in your software.
Also, because of this you tend to give it general rules which are not always
right.
There are
It does not understand the real dependencies in your software.
what does understand mean in that context?
I would think if this is all done automagically with go it would need
to follow even more general rules, no?
mk doesn't parses '#include' directives in C and even if it did, it
wouldn't help.
I think that's what hes referring to.
2013/3/25 hiro 23h...@gmail.com
It does not understand the real dependencies in your software.
what does understand mean in that context?
I would think if this is all
On Mar 25, 2013, at 11:33 AM, hiro 23h...@gmail.com wrote:
what does understand mean in that context?
I would think if this is all done automagically with go it would need
to follow even more general rules, no?
No, they are concrete and specialized for go (the language). Go (the tool)
knows
On Mar 25, 2013, at 11:40 AM, Bence Fábián beg...@gmail.com wrote:
mk doesn't parses '#include' directives in C and even if it did, it wouldn't
help.
I think that's what hes referring to.
Yes.
On Monday 25 of March 2013 11:33:55 hiro wrote:
It does not understand the real dependencies in your software.
what does understand mean in that context?
I would think if this is all done automagically with go it would need
to follow even more general rules, no?
if mk understood 8c's
On Monday 25 of March 2013 11:40:32 Bence Fábián wrote:
mk doesn't parses '#include' directives in C
gnu make can use output of gcc -M as rules describing prerequisites. it's
somewhat tedious and error-prone, though, as indicated by multitude of -Mx
file options.
--
dexen deVries
What if you want to make postscript from troff files?
Mk is a general tool and a good one. But it will never
have intricate knowledge about the files it works on.
2013/3/25 dexen deVries dexen.devr...@gmail.com
if mk understood 8c's construct ``#pragma lib libbio.a'' and used it to
link
On Mon, Mar 25, 2013 at 11:43:36AM +0100, dexen deVries wrote:
if mk understood 8c's construct ``#pragma lib libbio.a'' and used it to
link
correct libraries, it could be said to understand the actual dependencies as
expressed by code.
Except that there is a topological sorting to be
On 25 March 2013 11:16, tlaro...@polynum.com wrote:
since the
linking with libraries is order dependent. And one will need to
explicitely state that some lib depends on some others for the
linking (except if the symbols in the library are scanned to detect
unsatisfied dependencies and a
On Mon, Mar 25, 2013 at 11:55:19AM +, Charles Forsyth wrote:
the loaders do that using pragma lib:
The order of search to resolve undefined symbols is to load
all files and libraries mentioned explicitly on the command
line, and then to resolve remaining
On Mon Mar 25 07:10:21 EDT 2013, beg...@gmail.com wrote:
What if you want to make postscript from troff files?
Mk is a general tool and a good one. But it will never
have intricate knowledge about the files it works on.
mk does know how to expand and archive (see ar(6)) and
tell if the source
On Mon Mar 25 06:27:26 EDT 2013, pau...@gmail.com wrote:
anybody care to explain what is the limitation of mk here? can't
wrap my head around it...
It only knows about the rules you give it. It does not understand the
real dependencies in your software. Also, because of this you tend
neither is a big issue in practice. but that leads me to an interesting
question, does go rebuild everything if the go compiler has changed?
i think it stops at package runtime. at least that's what it builds
first when I tell it to rebuild everything.
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
if mk understood 8c's construct ``#pragma lib libbio.a'' and used it to
link
correct libraries, it could be said to understand the actual dependencies as
expressed by code.
of course, the deeper you go into this rabbit hole, the closer you get to
something resembling GNU autotools.
I
17 matches
Mail list logo
