Re: Naive DEFSYSTEM replacement

1) Makefiles were written for a world in which compiling some files did not change the behavior of the compiler when compiling other files. CL is not in that world. (Neither are several other languages, e.g. Ada, which have similar issues with just expecting ‘make’ to both work, and save effort on the old machines in use at the time Ada was more commonly used at least by defense contractors).

2) There are tools outside of the Makefile (e.g. gcc’s -MD and -MP flags) that do a static analysis of a file while compiling to generate a dependency list which can then be (automatically) integrated with the makefile. These basically look for, e.g. #include directives to note what include files are needed, and presented to the compiler *while compiling that file*. 

This wouldn’t be of much help to a program whose dependencies are based on, e.g. symbols synthesized at compile-time inside of macros. (consider checking file ‘b’ which uses a macro from file ‘a’, but you checked ‘b’ first, so all you see is a potential function that isn’t defined in that file. How do you know at that point it’s a macro that will end up calling a function defined in file ‘c’ based on its expansion? Later when checking ‘a’ you now know it’s a macro, but you probably didn’t maintain the actual call state allowing you to see that a call to ‘c’s function was created. So you might be able to say that a must be compiled and loaded before b is compiled, but you’d miss the reference to c until you tried doing that.

And let’s not even mention perfectly legal self-modifying code — added via macrology to the compiler (i.e. macros that rewrite themselves). Aren’t powerful languages fun?

So even if you had a tool that provided such an analysis, it would potentially be wrong unless you fed it the files in the correct order to begin with, and you wrapped them with enough pragmatic knowledge of how they are used to be able to decide what the impact is both on the general ordering, and what changes require recompilation of other files.

If this is a major concern to you, my suggestion would be to figure out a tool that would help solve these problems absent knowing the intentions of the programmer (sure, it’s undecidable in general, but any progress would be something). Alternatively you can define a metalanguage that can be used to state the programmers intentions explicitly, perhaps in a nice (declare …) term.

Such a tool would be a great contribution to the community (both lispers specifically, and general computer science, I expect).


> On Jul 25, 2025, at 4:16 AM, Adam Weaver (as adam at cleversure dot com dot au) <[email protected]> wrote:
> 
> ... just strikes me as nutty. Makefiles might be weird, but they work!
> Why don't we have an easy Make replacement?
> 


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html