LispForum

I wrote a blogpost about it.(edit: please read the link) The format i suggest is to put into a file with nothing else in it:system-name is a symbol giving the name identifying the system.

other-system just the names of systems it depends on directly. That means it must also list it when both indirectly and directly. The system it depends on might not do so in the future.

part is a subsystem the system is build on, and part-name is a symbol or a string, just the name is an empty subsystem. depends-on inside parts can only refer to other subsystems.

Extension-claimed-data is a list starting with the name. This could be any data that is used by convention.

It is very simple and consistent, but not flexible.

Currently, asdf has many more features than those. You can, for instance, define methods, specially for asdf:operation (for instance, to define how to test a system, or how to do some tricky loading of some sort). You can also state which kind is your file, separating Lisp source from, e.g., C source, documentation, text files, license...

Trying out an idea that doesn't depend on creating a new package just to define your system is very clean. I would do it without changing compatibility with current system definitions, though.

I believe that currently the biggest problem with asdf is not to support that lame OS that don't use symbolic links. That and asdf-install, which you can substitute with clbuild or something else.

How about improving it by actually printing the error message out instead of returning a relatively undescriptive error ' <compiler-op nil>: error when compiling file _>, or something like that. Not very helpful for fixing errors in files, currently.

@gugamilare first paragraph of the link, methods are a problem. If the dependency file depends on more things than the dependency system, it is broken. Further, defining functions in the file determining the dependencies conflates extending the dependency capabilities and just adding a system. If you want to extend it do it from a separate system, figure out what extra optional information is to be available.

Tbh I don't like 'tricky loading', but i guess one could add a :run-file-before-compile or something. Same for testing, just add an attachment system :test, and then :run (Of course, it must be made official that it is to work this way.

gugamilare wrote:You can also state which kind is your file, separating Lisp source from, e.g., C source, documentation, text files, license...

Well, what i have written so far has something like a file-hook, what i have written ontop of that currently does it with the file extension, i can imagine that people want to specify the type from the file, though. I guess that can be added, perhaps a :file-type in a system will make files from that system of that type and the value of it to be passed into the file-hook. Extensions can then work via the file-hook.

gugamilare wrote:I believe that currently the biggest problem with asdf is not to support that lame OS that don't use symbolic links. That and asdf-install, which you can substitute with clbuild or something else.

Is it really that much of a problem? Can't you just manually add all the systems you want into asdf:*central-registry*? I started doing it that way in linux, found making all the damn symlinks too much fuss.

@Suroy, i am speaking mostly of the format right now, not really implementation. You are right though. Another thing that would be nice is to have extensions that can check that it lists the direct dependencies, and nothing less(more). If system A directly depends on B and C, fails to indicate that it depends on C, and B depends on C, that will work, because B loads C for A. But if a next version of B stops relying on C, the dependency specification of A breaks.

Jasper wrote:@gugamilare first paragraph of the link, methods are a problem. If the dependency file depends on more things than the dependency system, it is broken. Further, defining functions in the file determining the dependencies conflates extending the dependency capabilities and just adding a system. If you want to extend it do it from a separate system, figure out what extra optional information is to be available.

If you create a method that is depends on something else than ASDF (that would probably be an extension to ASDF), it is simple to check if the extension is actually available before using it, or loading that extension before doing anything else. If the user does not do it, it is the user's fault, not ASDF's. Most simple uses don't need such extensions anyway. But changing that with a "hook file", I wouldn't trust it works in every case (because compiling is not the only thing you might want to do with a system) and it looks like a dirty hack.

Being extendable is a great feature from ASDF, I don't think it should be just thrown away. asdf:operation is a method, so why impeaching its use?

Jasper wrote:

gugamilare wrote:I believe that currently the biggest problem with asdf is not to support that lame OS that don't use symbolic links. That and asdf-install, which you can substitute with clbuild or something else.

Is it really that much of a problem? Can't you just manually add all the systems you want into asdf:*central-registry*? I started doing it that way in linux, found making all the damn symlinks too much fuss.

I guess it ends up in personal preference, but apparently most Lispers like symlinks, and I've seen a lot of complains for lack of a better integration with Windows. Symlinks also make automated systems like clbuild work better.

Mistakes like these are made rather often, looking at Juan Garcias analysis. There is no reason to allow the possiblity of the mistake to exist, if the .asd file were datalike and people just made additional form elements.

Further if you look for instance at Arnesi there, there is no way to determine ahead of time what the test depends on, unless you do scan code, which doesn't guarantee you find it, and is way more involved than it should be. It is also not easy to figure out which systems are meant to be systems that test things, and which are meant for users. Worse, users are sometimes tempted to add dependencies to systems that are really only needed for the test.

And if you look at the various forms the analysis shows, you see symbols #: a lot, obviously this is to avoid using symbols that don't exist yet. However, this potentially leads to name clashes for defparameter/defvars/defuns etcetera.

gugamilare wrote:Being extendable is a great feature from ASDF, I don't think it should be just thrown away. asdf:operation is a method, so why impeaching its use?

Because this way of extending creates potential problems, and makes some information much harder to machine-read. A better way of extending is having some place where conventions on names for different are listed, and people can ask for more of them, and them making the asd+ files list the information as data, and the extensions live as loadable library/tool to use that data.