On Thu, Dec 19, 2013 at 2:16 AM, dexen deVries wrote:
> the problem is not solved, merely one of the manifestation is eliminated.
> actual solution requires stating all the dependencies.
>
> if your list of sources and/or targets is dynamic, consider using mkinclude:
> <| GEN_DEPS
> where `GEN_DEP
the problem is not solved, merely one of the manifestation is eliminated.
actual solution requires stating all the dependencies.
if your list of sources and/or targets is dynamic, consider using mk include:
<| GEN_DEPS
where `GEN_DEPS' is your script generating deps in form TARGET: PREREQUISITE
O
Thanks. That is what I was wondering. In the interim, and having a better
understanding of what is going on, I was able to re-work my mkfile to
support parallel builds where possible. I am, however, experiencing a new
problem. I will write that up in a separate post.
Thank for the info!
Blake
You could put NPROC=1 in the mkfile.
The problem is solved, but I do have questions that I couldn't the answer
to in any of the docs.
On Wed, Dec 18, 2013 at 9:37 AM, dexen deVries wrote:
>
>
> -s won't help you there, because it regards processing of /command line/
> arguments, not of prerequisites. consider:
>
> $ NPROC=1 mk my_ta
In particular, why would manual execution while echoing $status (to be sure
no errors are reported) work, but mk execution of the exact same sequence not
work?
Thanks!
Blake
On Wed, Dec 18, 2013 at 12:20 PM, Blake McBride wrote:
> In response to both of you:
>
> On Wed, Dec 18, 2013 at 11:28
In response to both of you:
On Wed, Dec 18, 2013 at 11:28 AM, Blake McBride wrote:
> ...
>
> I remain confident that there is a thought out, reasonable algorithm
> employed by mk that I am yet ignorant of.
>
> Blake
>
>
If you could point me in the right direction, I'd surely appreciate it.
On
On Wed, 18 Dec 2013 11:28:21 CST Blake McBride wrote:
>
> I'd be a better judge if I understood the purposeful, thought out reason
> behind the problems I am experiencing - assuming there is one. "That's
> just the way it works" or "we do it differently because we are not unix"
> are stupid as h
Quoting Blake McBride :
I'd be a better judge if I understood the purposeful, thought out reason
behind the problems I am experiencing - assuming there is one. "That's
just the way it works" or "we do it differently because we are not unix"
are stupid as hell arguments.
No they aren't.
Meanw
Often there is a set of reasonable, alternative algorithms one may utilize
to solve a problem. Then, there is a set of unreasonable algorithms one
may employ that may or may not solve the problem given various conditions.
"make" has a proven reasonable algorithm to solve the problem for which it
Seeing a Go link on your homepage I thought, oh, you also program in go?
And then found that you actually *play* go (Google harmed a lot looking for
information on the game). More surprising :D
On Wed, Dec 18, 2013 at 6:18 PM, Blake McBride wrote:
> This is not D. It is a language of my own de
This is not D. It is a language of my own design called Dynace. It adds
multiple inheritance, a metaobject protocol, generic functions, weak
typing, garbage collection all to standard C. Class users (*.c files) are
standard C in every way, there is only one data type added. The system is
writte
D on Plan 9? This is madness.
--
Aram Hăvărneanu
On Wed, 18 Dec 2013 10:11:22 CST Blake McBride wrote:
> >
> > Somehow Unix or GNU "make" doesn't mix up buffered stdout with unbuffered
> > stderr output. They remain in order so the total out of make and all of
> > the commands are shown in order and in context. You know, so a human can
> > und
On Wed, Dec 18, 2013 at 9:23 AM, Blake McBride wrote:
>
>
> Problem 3:
>
> Somehow Unix or GNU "make" doesn't mix up buffered stdout with unbuffered
> stderr output. They remain in order so the total out of make and all of
> the commands are shown in order and in context. You know, so a human ca
Thanks for the help! See below:
On Wed, Dec 18, 2013 at 9:37 AM, dexen deVries wrote:
> On Wednesday 18 of December 2013 09:23:19 Blake McBride wrote:
> >
> > Problem 1:
> >
>
>
> it seems you have an un-stated dependency/cies among your intermediate
> targets
> / prerequisites.
>
> Say, foo.o
On Wednesday 18 of December 2013 09:23:19 Blake McBride wrote:
>
> Problem 1:
>
it seems you have an un-stated dependency/cies among your intermediate targets
/ prerequisites.
Say, foo.o depends on foo.c and foo.h -- but foo.h also depends on
generated_foo.h, which should be generated by mak
Greetings,
I have spent hours on a trivial problem that I still haven't figured out. I
am using 9front, and I am building a C app using mk. I understand about
that parallel stuff so I am calling mk with -s for now. There are actually
three problems, but the fact that it won't build is clearly th
18 matches
Mail list logo
