Depending on and generating files in system definitions

[Robert Goldman]

On 6/28/16 Jun 28 -1:57 PM, 73budden . wrote:
> What about #. ?
> 
One can, of course, use #. to set any part of a system definition.

But it's worth thinking about how this could go awry.

E.g., if you list all the files in the system definition, in the classic
way, and you add a file, the system definition file will change.  If you
try to load the system again, ASDF will notice that the .asd file has
changed, and reload with your new file.

OTOH, if you create a set of components using #. and DIRECTORY, and the
directory contents change, the asd file will not have changed, and ASDF
will not notice anything, and you will get something wrong if you try to
load the system again.

TBH, I don't like these computed component list ideas because to do the
right thing, in general, we'd need to have a lot of additional machinery
to make ASDF correctly notice when the computed components should change.

IMO, that's a lot of engineering to save someone from having to type

(iter (for file in (directory "*.lisp"))
      (format t "(:file \"~a\") (pathname-name file)))

and paste the results into the .asd file.

Also, as has been pointed out previously, CL does not have glob
patterns, so wildcard matching is very weak.  To do better than "match
all" or "match all of type X" you need to load a regexp library, and
iterate over namestrings from a call to DIRECTORY.

As I said, that's a lot of engineering to avoid typing a file manifest.
I'm not ruling it out, but I'm not enthused.

Of course, if someone wants to use #. that's fine -- it's not my problem
if it goes wrong.  But if we put it into ASDF and it goes wrong, it *is*
my problem.

Best,
r