From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5446730.4oMZM0t5oA@coil> References: <5446730.4oMZM0t5oA@coil> Date: Wed, 18 Dec 2013 10:07:43 -0600 Message-ID: From: Blake McBride To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e0122f6aebcda5604edd13e04 Subject: Re: [9fans] Problem with mk Topicbox-Message-UUID: 9f110366-ead8-11e9-9d60-3106f5b1d025 --089e0122f6aebcda5604edd13e04 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the help! See below: On Wed, Dec 18, 2013 at 9:37 AM, dexen deVries wro= te: > 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 make. > > in such case, explicitly state (no recipe is necessary): > > > foo.h: generated_foo.h > > > so mk knows the `generated_foo.h' must be completed first. > Yea, actually my build process is a bit more complex than that. What I am doing reflects that complexity and works perfectly with make. _Initially_ (the first time), generics.h gets built through the generics.1 target, and then updated through the generics.h target process. Thereafter, as the program evolves, new classes are added (*.d files) and changed, generics.h gets updated through the generics.h process only. The generics.h target process reads in generics.h and updates it based on the changed *.d files. You can think of generics.h as a database of generic functions that needs to be initialized and then updated as the system evolves. The purpose of using rules rather than explicit recipes is because the mkfile is often used as a template for much larger projects. The pattern is convenient. Larger projects just have to update the three variables TARGET, CLASSES, and CFILES. If I don't use recipes, the mkfile gets unnecessarily lengthy with larger projects. Also, in spite of my use of a recipe rather than an explicit rule, why would that cause mk to barf? > > > > Problem 2: > > > > Even though I am executing mk with the "-s" option, it still seems like > it > > is running in parallel because a subsequent command can't find a file > > created by a prior command - as if it didn't wait for the prior command > to > > finish. Remember this build fine, and without error codes, when > executed > > manually. > > > > -s won't help you there, because it regards processing of /command line/ > arguments, not of prerequisites. consider: > > $ NPROC=3D1 mk my_target > > also investigate -d[egp] debug stuff. > Yes, I didn't see a difference with or without the -s. I just used it to eliminate one possible source of problems. Also, the random intermixing of stdout and stderr causes me not to know what the order of execution is. > > > have fun with mk, it's a great little tool :-) > I'm sure it is. If I can get it to treat generics.h as a database as I described above, it would be great. Thanks! > > > > -- > dexen deVries > > [[[=E2=86=93][=E2=86=92]]] > > Take care of the luxuries and the necessities will take care of themselve= s. > -- L. Long > > > --089e0122f6aebcda5604edd13e04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the help! =C2=A0See below:


On Wed, Dec 18, 2013 at 9:37 AM, d= exen deVries <dexen.devries@gmail.com> wr= ote:
On Wednesday 18 of December 2013 09:23:19 Bl= ake McBride wrote:
>
> Problem 1:
>


it seems you have an un-stated dependency/c= ies 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 make.

in such case, explicitly state (no recipe is necessary):


foo.h: generated_foo.h


so mk knows the `generated_foo.h'= ; must be completed first.



Yea, actuall= y my build process is a bit more complex than that. =C2=A0What I am doing r= eflects that complexity and works perfectly with make.

_Initially_ (the first time), generics.h gets built through the generics.1 target, and then= updated through the generics.h target process. =C2=A0Thereaft= er, as the program evolves, new classes are added (*.d files) = and changed, generics.h gets updated through the = generics.h process only. =C2=A0The generics.h tar= get process reads in generics.h and updates it based on the ch= anged *.d files. =C2=A0You can think of generics.= h as a database of generic functions that needs to be initialized and then = updated as the system evolves.

The purpose of using rules rather than explicit recipes= is because the mkfile=C2=A0is often used as a template for much larger pro= jects. =C2=A0The pattern is convenient. =C2=A0Larger projects just have to = update the three variables TARGET, CLASSES, and CFILES. =C2=A0If I don'= t use recipes, the mkfile=C2=A0gets unnecessarily lengthy with larger proje= cts.

Also, in spite of my use of a recipe rather than an exp= licit rule, why would that cause mk=C2=A0to barf?

=C2=A0


> Problem 2:
>
> Even though I am executing mk with the "-s" opt= ion, it still seems like it
> is running in parallel because a subsequent command can&#= 39;t find a file
> created by a prior command - as if it didn't wait for= the prior command to
> finish. =C2=A0Remember this build fine, and without error= codes, when executed
> manually.



-s won't help you there, because it regards processi= ng of /command line/
arguments, not of prerequisites. consider:

$ NPROC=3D1 mk my_target

also investigate -d[egp] debug stuff= .

Yes, I didn't see a difference with or= without the -s. =C2=A0I just used it to eliminate one possible source of p= roblems. =C2=A0Also, the random intermixing of stdout=C2=A0and stderr=C2=A0= causes me not to know what the order of execution is.
=C2=A0


have fun with mk, it's a great little tool :-= )

I'm sure it is. =C2=A0If I can get it = to treat generics.h as a database as I described above, it wou= ld be great.

Thanks!
=C2=A0



--
dexen deVries

[[[=E2=86=93][=E2=86=92]]]

Take care of the luxuries and the necessities will take care of themselves.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- L. Long



--089e0122f6aebcda5604edd13e04--