Alec, Thanks for publishing this. A few Win32-centrict comments...
- If possible, it would be better form to generate the temp file generated in processing the REQUIRES list into the WIN32_?.OBJ dir rather than the source dir. - I notice that 'depend' now forces an export phase. This means that "depend build_all" would result in two export phases. I see that a 'build_all_dep' target was added to client.mak to avoid the duplication. That is great. But I wonder if this got any publicity. FWIW, I'd have called it 'build_all_depend' or 'depend_build_all'. The abbreviation of 'depend' seems gratuitous. - I wonder out loud again if there is still any real reason to be building js/src during the export phase. At one time this mattered. But I doubt it does any more. I haven't tried to change it to see. With depend happening after export this leaves js/src out in the cold for dependency tracking. Luckily, js/src requires only nspr - whose early build is hardcoded into the make system. Still this is an oddity that we should maybe fix if it is no longer needed. - And... I sometimes build on my WinME machine and it seems to be broken now. With a completely fresh pull it fails in modules/libreg/standalone because it can't find NSReg.h when building reg.c. Is the REQUIRES processing expected to work on Win9x? config.mak looks to have Win95 specific code for this. Is it tested? It does not seem to be working for me. Maybe I need some additional perl package or something? My build worked before. But I have not noticed anyone else complaining since you checked in your change. Any ideas? Thanks, John. Alec Flett wrote: > > You might be wondering what is up with this REQUIRES system that we just > added to the build. > Even if you know how to use REQUIRES, read this and learn how to use > REQUIRES to make a neat graphical view of your modules! > > What's the point of REQUIRES? > Here's the deal. > We're trying to reduce inter-module dependencies by creating an easy way to > 1) alert developers when new code introduces a dependency > 2) provide a way to track inter-module dependencies in an easy way > > How does it work? > The REQUIRES system is fairly simple: > 1) The module is declared in the makefile which exports these headers in > the MODULE variable. For instance, the "necko" library declares > "MODULE=necko" All the exported headers from a particular module > aredumped into a subdirectory in dist/include which corresponds to that > module. For instance, the "necko" headers end up in dist/include/necko. > 2) When one module wishes to use the public headers from another module, > they list that module in the REQUIRES variable in their makefile. For > instance, if the "msgimap" module needed to use necko, it would add > "necko" to the REQUIRES variable. This will add an include to the > compiler command, such as -I$(DEPTH)/dist/include/necko. > > How can I graphically view my modules and their dependencies? > There is a tool in mozilla/tools/module-deps called "module-graph.pl". > This script will crawl a list of specified directories, and output a > text file which describes a directed graph. Using the GraphViz package > from AT&T research (http://www.research.att.com/sw/tools/graphviz/) you > can turn these graph descriptions into a .png with circles and arrows. > > for example, to track necko, xpcom, and string dependencies, you would say: > > c:\tree\mozilla> tools\module-deps\module-graph.pl netwerk xpcom string > > xpcom-necko.dot > c:\tree\mozilla> dot -Tpng xpcom-necko.dot -o xpcom-necko.png > > Now just look at xpcom-necko.png and see what you get! > > (The module-graph.pl script will work on both windows and unix, as will > the GraphViz package) > > Enjoy! > > Alec
