Thanks for the help! See below:
On Wed, Dec 18, 2013 at 9:37 AM, dexen deVries <dexen.devr...@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 > > >
