John et al, > My concept is that build systems are just programs like any other.
But not really just like any other because of what they do. You might not get that impression from the Judy makefile I mostly wrote, but I am something of an expert on software build and delivery systems. I won't expound at length but want to mention that the idea of a data flow diagram (DFD) is a powerful model for what a build system is really all about, what it implements. Repositories (files) flow through processes (programs/etc) into other files. (DFDs are to control flow diagrams as higher-level declarative languages are to lower-level functional languages. You can google and read a lot more about DFD theory if it's a new idea to you.) When the build sources/targets are small enough relative to current technology, we just rebuild everything from scratch all the time and the build system can be relatively simple. In real life though we always need conditional (re)build systems that understand dependencies and how to do efficient partial rebuilds. Part of the art is how to correctly and efficiently "templatize" myriad repetitive patterns (rules) that have some variations. The most complicated build system I've ever seen was for chip design flows, where multiple different sets of sources could be used to create multiple different sets of outputs depending on what sources were available, and there were series of pattern-matching distinguishers for when to do what within each "rule group". Anyway one other drive-by concept worth mentioning is that real life often involves both multi-target rules and multi-rule targets (using make(1) terminology)... The correct handling of those concepts is philosophically difficult, and often gotten wrong. > Doug: you and Alan have to decide what to do here. To be clear it's 100% Doug's project now, has been for years. I often respond to emails trying to be helpful if he doesn't, and we live in the same general area, but haven't worked on libJudy together since 2002. He's retired, I'm mostly not yet, and he's the sole owner of the library, I'm just a user now. Which means I'm not reading every word of the current discussion as it gets involved! :-) Cheers, Alan Silverstein ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
