Preliminary analysis of existing ASDF practices
in [Lisp]
|
Prev: Is LISP divine?
Next: keywords & macros
From: Thomas M. Hermann on 14 Apr 2010 10:30 On Apr 14, 9:25 am, "Thomas M. Hermann" <tmh.pub...(a)gmail.com> wrote: > On Apr 13, 10:38 am, Juanjo <juanjose.garciarip...(a)googlemail.com> > wrote: > > > ... and some ideas about the future. Some of them affect how existing > > systems can be integrated with a particular implementation, ECL, but I > > hope you will be able to see beyond that. > > >http://tream.dreamhosters.com/tream/musings/49-lisp/76-analysis-of-ex... > > > Comments better here at comp.lang.lisp > > I use ASDF, but my use is very rudimentary, so I generally don't run > into the issues other people are encountering. Based on the number of > criticisms I've seen, though, apparently I'm just not sophisticated > enough to appreciate the failings of ASDF. > > I think it would be useful to get copies of existing systems, contrive > examples, including pathological ones, apply each system to the > example and analyze. The systems that I am aware of are: > > - mk-defsystem > - ASDF > - XCVB > - mudballs > > The mudballs project has been discontinued and the website is down, > but there is a point of contact for the author in the final Google > groups message. > > To put the issue in context, look at the myriad of build systems for > other languages. Personally, I like good ol' Makefiles, but, then > again, maybe I'm just unsophisticated. So, is the goal a lisp only > build system, or will it support defining rules and dependencies for > building other things? I think a solid core that is lisp focused with > 'contribs' for other things would be ideal. > > ~ Tom Should have included this link: http://en.wikipedia.org/wiki/List_of_build_automation_software ~ Tom
From: o.jasper on 15 Apr 2010 13:25 It seems to me like you are making it more complicating than it is. History has lessons, yet, but it is also a sea of words and information to drown in.. How about a more theoretical approach, let each system is just a bunch of nodes in a bunch of different graphs. Each graph corresponds to an action one can do on the system. All the asdf replacer needs to do is:(Trying to more clear than i was in lispforum.org * Locate keep track of and read the asdforms. (defsystem should next to the regular files also store *load-pathname*) * Make conventions for the asdform, how it refers to files and other systems, and some extras like :description. * Allow action writers to specify dependencies based on this data. Probably in many cases exactly the files/systems listed(it should be the default) * Allow writers to leave information on the state; for instance, denoting that it has been compiled, with date/md4 checksums. This is _completely_not_ a compilation, tool, it is _only_ a dependency tool, but one that allows for compilation if such action is defined! So whatever compilation and loading tool we will want can then use this as a library for its purpose, the library itself not containing any actions itself. Advantages of viewing it this way: * The dependency library can also be useful for other things. * Multiple people can register the same sort of action, you could have :load :compile to be the defaults of the implementation/user, or you could have it :sbcl-compile, :ecl-compile(if the C code can then be cffi-ed in), etcetera. * It is simple and clear. New actions might even add conventions to the asdform above. (But preferably uses ones that) Just to prove this is infact not hard, http://ojasper.nl/src/lisp/dep/dep.lisp, i suggest something like that, except for better potential clearness of dependencies between the files.(Like asdf provides) If you think it can't do something, we'll have to look at that, of course. But i see no real limitations. It is also not complete, no storing of the systems or data submitted to them yet, and one would also like to document the conventions used in the Def-a-system form. Maybe one would also like to give the user some tools to indicate where he has been already and such. PS,BTW there is an automatic .asd file creation system in my project http://lisp-editor.berlios.de/, but i am not satisfied about it, i should try it on the project itself. And it sillilly writes directly to file instead of making the defsystem form and then writing that to file. It works by expression-scanning the files, and then making an system for each of the packages based on :use and what other external symbols it found within the package.
From: Juanjo on 15 Apr 2010 14:38 It may just as simple, but some people believe it should be more complex. 1) Dependencies should be different depending on the "action". That complicates things quite a bit. 2) Some actions trigger other actions (:compiled -> :load or :load - > :compile). That is even more complicated. All this complexity, which does not exist in defsystem, plus the sophisticated and too powerful CLOS API for building additional operations and components, is what makes ASDF both powerful and incomprehensible.
From: Nathan Froyd on 15 Apr 2010 16:06 On Apr 13, 6:29 pm, Juanjo <juanjose.garciarip...(a)googlemail.com> wrote: > Now the question is whether it pays of to "fix" ASDF, we jump on the > XCVB wagon or we wait for some kind of illumination to write the next > big thing. What is wrong with being lazy and > > * Give people tools to write better *.asd files, side-effect free. This is the big sticking point in switching to something else. There are good reasons why side-effectful bits are useful in an .asd file. Custom component definitions and specializing operations on those components are what come immediately to mind > * Restrict the set of operations that ASDF supports to a few: compile, > load & test Please don't do this. There are very good reasons to support more than three operations on a system; I've written at least two custom operations for my own personal use (building tar files and autogenerating documentation); I'm sure you can think of more. > * Simplify the way components are written, perhaps adding some > syntactic sugar. > * Create an API to load and traverse the set of systems and their > dependencies. This would be something useful standalone; coaxing a list of files out of ASDF can be an exercise in frustration. Doubly so if you want system-relative names. > * Replace the routine that drives ASDF, TRAVERSE, with something > everybody understands. Method combination would be a good start here. TRAVERSE was written the way it was because of poor CLOS support from some implementations. -Nathan
From: Mario S. Mommer on 15 Apr 2010 16:12
Tim X <timx(a)nospam.dev.null> writes: > m_mommer(a)yahoo.com (Mario S. Mommer) writes: > >> Juanjo <juanjose.garciaripoll(a)googlemail.com> writes: >>> On Apr 14, 6:14 am, Tim X <t...(a)nospam.dev.null> wrote: >>>> 2. I would love a system similar to CPAN. I'd love to be able to just >>>> issue the command CLAN install <some-lib> and hav it identify any >>>> dependencies not available locally, download all necessary sources, >>>> build them, run tests and if all goes well install everything. >> >> My experience with CPAN has always been negative. It just did not work >> that way, and in fact for me it did not work. >> > > That is interesting. In the 10+ years that I have used it, I've only had > a couple of times where it has let me down and without exception, that > was due to bad decisions on my part. This is not to say I think its > perfect. There are a few issues I've learnt to watch out for, but in > an overwhelming majority of times, it has worked without a hitch. I > frequently find a search to identify possible modules, together with a > bit of background searching to see if anyohe has had issues with those > modules and then a simple cpan -i <module name> and a few minutes later > I'm coding with that module. I know 0 perl, so I went by what the docs said on how to install things. IIRC, I was trying to install one of the mail.yahoo to mbox thingies. Neither the stuff packaged with debian or ubuntu, nor the straight-from-upstream thing worked. Lots of errors, many pertaining to hard-coded paths in whatever makefilelike facility was used, others about incompatibility of modules. It just bombed over and over until I just stopped. I repeated that exercise twice with a few years appart, the last time about two years ago. > The fact you have had problems with CPAN means you are likely to have > some really valuable input into issues to watch out for, features that > would be useful and things that may be best avoided. Well, as I said, 0 perl here. So I am afraid I can't really say much beyond "it did not work for me". >> Maybe a good starting point would be to find out if such a thing is >> possible. I mean, it certainly sounds like a good idea, but given the >> many decissions that are conditional on context (load-load-load-dump >> vs. alternatives, for example) I am not too optimisitc. Make & co >> certainly do not do it that way, I think. > > Well, its pretty difficult to determine if something is possible without > trying to do it. Some concrete suggestons on how this could be done > would be useful. ASDF went ahead and tried it, and did a reasonably good job to bring things to one standard, so that's what we are complaining about know, instead of a lack of standards. Without any sarcasm I'd say we have progressed. > What we need is concrete examples, not theoretical or vague 'gut > feelings' regarding where problems may or may not exist. I think the > object should be to improve the current situation, not aim for the > ultimate perfect outcome. Even if we completely fail, we are likely to > add additional knowledge that will be extremely useful for the next > attempt! Writing an .asd to compile and link some fortran files and then load the resulting .so is IMO already too complicated. If you want to use a compiler that is written in Lisp, the .asd itself cannot be loaded without the compiler being loaded first, because the symbols the compiler exports does not exist. That leads to the asdf:operate forms at the beginning of .asd. I think the most important part is really about policy. If software loader/builder scripts adhered to some common and good guidelines, and implemented the relevant scripts using some common library that made things easy to write and read, then we would be done. The general case includes people programatically downloading patches and applying them, etc, which is simply too much for a defsystem form to express cleanly and easily. Here's something on the lines of what I have in mind: (load-module "src" (load-file "file1" (load-file "file 2")) (load-file "file3")) where load module would append the directory "src" to some special, and the load-file would be implemented in a lazy fashion. This would cover the simple cases. It is possible, and IMO better, to do all the dependency tracking programatically and sanely, instead of doing it using some DSL (defsystem keyword maze) and then going through hoops to define and modify the dependencies and operators, etc. |