Mike Kupfer wrote: >>>>>> "Mark" == Mark J Nelson <Mark.J.Nelson at Sun.COM> writes: > > Mark> 116/123: the $(CLEANCHUNKDIR) dependency seems like it might be a > Mark> little bit misplaced, in that it's part of the dependency chain of > Mark> rawchunks instead of $(ONCHUNKS). Seems like there could be a > Mark> race condition for a fast, parallel build, where something could > Mark> fire the actions on 142 (and therefore 136) before 123? > > Mike> This is serial make (no .PARALLEL target). IMO it's not big enough > Mike> to be worth trying to parallelize. > > Mark> I still think the dependencies should sort correctly, though. I > Mark> don't think there's a guarantee for which target will be built > Mark> first, is there? > > I thought that dependencies were processed depth-first, left-to-right, > though I can't find anything in the documentation that specifically says > that.
I have the same impression; it gets done consistently, but I couldn't find a guarantee. > If it's not something we can rely on, I think this is also an issue for > ON makefiles, like this bit from uts/Makefile: > > install: all_h install_dirs $(PMTMO_FILE) $($(MACH)_ARCHITECTURES) > > (The $($(MACH)_ARCHITECTURES) builds depend on the header file > generation that is done in "all_h".) Yeah, it would be great if the ON makefiles were a good example. Or if it was easy to tell WHICH of them were good examples. But you're right, I'm holding this simple, limited scope example to an inappropriate standard. > But the good news here is that your suggestion does simplify the > makefile quite a bit, and it makes this particular dependency question > go away. Cool. I think this is easier to follow. It takes the deterministic sequence that you were already following and lays it out in one action. > Updated webrev is at http://cr.opensolaris.org/~kupfer/devref-chunks/. 116, 118-120: I think that the conditional on 118 should be removed, and this concatenation moved to outside the loop. Not sure about shell rules for successive invocations, it might be safer to manually remove ch03b.html before (re)creating it. If you keep it as a single subshell, then the whole thing would end up looking like 116 cd $(RAWCHUNKDIR); \ 117 mv apa.html glossary.html; \ 118 rm ch03b.html; \ 119 cat ch03b1.html ch03b2.html > ch03b.html; \ 120 for f in $(ONCHUNKS); do \ 121 python ../fixup.py < $$f.html > ../$(ONCHUNKDIR)/$$f.html; \ 122 done 126: "ch*.html" already covers everything matched by "ch*s*.html" 125-127: should probably be prefaced with "-" so that "make clean" doesn't fail for an already-clean directory. Could combine 125 and 126, but I'm not really picky about doing so. > Mike> For some reason fixup.pyc is no longer being created, so I removed > Mike> *.pyc from the "clean" target, too. > > Mark> Permissions? It should be there, somewhere, I think. > > That's what I thought, but it's not. The permissions are fine. Maybe > it's because it's invoked as "python fixup.py", not "fixup.py"? It's the fact that it's executed directory, and is not a module that's imported by other python code. --Mark
