On Wed, 27 Aug 2003 14:19:47 -0400, Noel Yap <[EMAIL PROTECTED]> said:
> [EMAIL PROTECTED] wrote: >> >> On Wed, 27 Aug 2003 07:37:46 -0400, Noel Yap >> <[EMAIL PROTECTED]> said: >> >> >> I would like a way to list all dependencies and subdependencies >> >> of a given target to avoid the recursive shell function hackism >> >> I currently have to do when using "make -pnq". >> >> > IMHO, don't use recursive make: >> > http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html. >> >> I get a file not found error at thet URI, but the recursion is not >> the major point here. Indeed, the recursion here may not even refer >> to using make recursively -- the point here is to discover all the >> targets that would be looked at when I run make. So, if the target >> of interest is "install", which depends on "build", which depends >> on my-program-name, which depends on main.o, which depends on >> main.c, which depends on /usr/include/stdio.h; I want to have all >> these dependencies listeed -- and I am justusing a simple Makefile. > Sorry for not checking the URL. If you're still interested in the > paper, googling for "recursive make harmful" turns up many links. OK. But I think we are being bitten by semantics -- the paper refers to inefficiencies in complex build environments that are only peripherally relevant in this feature request. The solution proposed in the paper, a single, humongous Makefiule (even if it is practical, which I personally think is only practical for small projects), would still have the same problems determining the dependencies involved. In the language of the paper, what is being requested is a listing of the nodes in the DAG. >> > If I'm misunderstanding the problem, can you provide more >> > details, please? >> >> All right. Suppose I want to create a wrapper around make that >> would call make automatically when one of the files that a make >> target depends on changes. How do I discover what those files are? > I don't understand, make already does this. Why not just call make? Perhaps because calling make is more resource heavy? Or perhaps the example provided was a simplified dummy example, and the real requirements are more complex. Suppose the project is to discover and document the impact of system/file changes on products/programs? >> Obviously, make knows, since when it is actually run it goes >> through, and tests files/targets to see if they need >> rebuilding. What is requested is a mode in which each target is >> assumed to be in need of rebuilding, but, instead of taking any >> action, all that is done is to print the target's name on stdout. >> >> I hope this is clearer. > Yes, much clearer. Have you tried "make -n"? The person requesting the feature has; but make -n only tells you the actions that shall be taken currently to update the target, not what all the dependencies are, I would not know, for example, that touching /usr/include/sys/time.h would cause the target to be rebuilt or not. make -np helps a little bit more, but at the expense of a lot of verbiage that one has to wade through. If it s a complex project being managed by Make, spread over several directories, with unknown dependencies in the Makefiles there, there is no easy way to determine a priori what the dependencies are, down the path. manoj -- Ship it. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make