> You are wrong. A dependency tracking system needs to be part of the > system, not just at the Make level, but also the system > level. Otherwise you get into obscure contorsions as exemplified by > the build of depsys.
Depsys exists for a reason. It handles things like macros in lisp and it removes things that are only needed at compile time from the final running image. If you miss the depsys dependencies you'll find that you get "clean" lisp compiles but the generated code is wrong due to missing macro expansions. This will show up as runtime bugs much later in the process, perhaps during algebra computations. Make and lisp have slightly different ideas about what it means to depend on something. If you actually list all of the dependencies at the Make level you'll find that you do a lot of unnecessary work. This only shows up when you begin to change a single file and do Make again. In theory Make should do the minimum amount of required work given all the dependencies. In a lisp based system this is very hard to do. A simple example is that the algebra code is built in layers. Each layer is built depending on the layers beneath it. Originally the algebra Makefile specified this dependency, which worked fine during the build. Yet if you change a single algebra file and do a second Make you can end up rebuilding a lot of the algebra needlessly. The current system dependencies were determined by doing a system build and then doing a modification to each kind of file, followed by a Make. In theory Make should only do a small amount of work to include only changes required. It took a fair amount of testing to determine the compromises between what Make needs and what lisp needs. Getting this right is important and requires a lot of testing. Tim _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
