Re: Naive DEFSYSTEM replacement

For what it's worth, Fare and I wrote a couple of articles for the 
International Lisp Conference about ASDF that addresses this issue. ASDF 
is the way it is substantially because it's NOT just a build system: 
it's a build system that must maintain the consistency of the running 
Lisp image. This is not a problem "make" has!

I should mention that I owe a lot of the conceptual grounding of this to 
Drew McDermott (z''l), who wrote an earlier paper about the even more 
fine-grained dependency system he developed for his "ytools" library of 
lisp tools.

ASDF is more complex than it should be (there's lots of stuff in there 
that I don't understand, and I'm the maintainer!), but the problem is 
more complex than most ASDF users think it is, too.

On 25 Jul 2025, at 11:43, Bradford Miller (as bradfordmiller at mac dot 
com) wrote:

> 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


Robert P. Goldman
Research Fellow
Smart Information Flow Technologies (d/b/a SIFT, LLC)

319 N. First Ave., Suite 400
Minneapolis, MN 55401

Google Voice:	(612) 326-3934
Cell: (612) 384-3454
Email:    [email protected]