Re: [9fans] Problem with mk

[Blake McBride <blake@mcbride.name>]

[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]

Thanks for the help!  See below:


On Wed, Dec 18, 2013 at 9:37 AM, dexen deVries <dexen.devries@gmail.com>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 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=1 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
>
> [[[↓][→]]]
>
> Take care of the luxuries and the necessities will take care of themselves.
>                 -- L. Long
>
>
>

[-- Attachment #2: Type: text/html, Size: 8601 bytes --]