Hello folks,
Excuse my bothering if this is not a correct place to announce. Nonetheless...
ASDlite Design Goals
1. Small footprint. 2 Ease of embedding into applications and systems not related to "compile-and-load Lisp files" tasks. For example: YstokHelp (http://lisp.ystok.ru/yhelp/) 3. ASDF compatibility for basic needs. 4. Operation arguments specification in dependencies.
Observation and Rationale
1. The ASDF built-in operation hierarchy is actually of two-level depth. Original ASDF code does not exploit operation inheritance much (though something can be found in asdf-ecl.lisp).
2. The operation slots are rather useless: original-initargs Is only referred in print-object parent In principle, indicates the target operation that required this one. But due to reusing operation objects in make-sub-operation, this is not the case. Also used for marking along with other visiting slots during traverse but we follow another approach.
Adding entirely new operations, i.e. on the first level, is fine. But there is comfortable way to refine existing operations: the easiest way is to add slots to base operation classes as only those properties do get passed into dependency operations.
There is a more simple way pass arguments from operate to operation functions - by means of key arguments!
3. The :do-first initarg is actually ignored by ASDF - its always set to ((compile-op (load-op ,@depends-on))))
4. Avoid inline methods, which are rather inelegant in ASDF: - they rely on eval, - ASDF tries to remove a method from a generic function of a different name. Due to non-standard behavior of remove-method in LW 4.4, system redefinition intrusively signals about this.
5. Referring to features in component definition is more useful than for dependency rules.
Operations in ASDlite
operation ::= keyword | operation-instance operation-type ::= keyword | type-symbol operation-designator ::= keyword | (keyword . plist) | type-symbol | operation-instance
Operations are passed to perform and other operation-specific methods. Operation designators can be used in the right-hand side of rules.
We encourage using simple keywords like :compile or :load. For these, ASDlite defines corresponding methods with eql specializers. The plist allows you to pass key arguments to the operation methods. In the "normal" mode, ASDlite accepts only keyword-based forms.
If you feel these are not enough and need "full-fledged" ASDF operation classes, you can switch to the ASDF compatibility mode as follows: - push :asdf-compat into *features* before compiling asdlite.lisp, - refer to asdf:compile-op, asdf:load-op and the like, - define your own subclasses of the operation class etc. In the compatibility mode, ASDlite accepts all the above forms of operations and designators.
Downloads and Details http://lisp.ystok.ru/asdlite/
-- Sincerely, Dmitriy Ivanov lisp.ystok.ru
Privyet Dmitriy,
On Mon, Apr 23, 2012 at 03:55, Dmitriy Ivanov divanov11@gmail.com wrote:
Excuse my bothering if this is not a correct place to announce.
It is a very correct place to announce this project. For ASDlite technical discussions, you may want your own mailing-list though, which you are welcome to announce here if/when you open it (I didn't see one on your page).
You are also welcome to discuss general Lisp build system design issues, as long as it doesn't devolve into anything too off-topic.
I have added your tool to the list of non-ASDF build system at http://common-lisp.net/project/asdf/#what_it_is_not Have you looked at the other ones?
ASDlite Design Goals
- Small footprint.
2 Ease of embedding into applications and systems not related to "compile-and-load Lisp files" tasks. For example: YstokHelp (http://lisp.ystok.ru/yhelp/) 3. ASDF compatibility for basic needs. 4. Operation arguments specification in dependencies.
For ASDF, we also strive for a small footprint, but put functionality and portability first. I admit I don't know how to make ASDF smaller without sacrificing something that will make some user unhappy.
There are many small simplications and improvements you make over ASDF that indeed would make sense if we had the luxury of not being backwards compatible; but your ASDlite still has the same basic model as ASDF. I don't see your system bringing enough new functionality for anyone to bother switching, much less everyone.
In the end, you're about the same size as ASDF 1, and about the same functionality. You have the same configuration issue as ASDF 1. There are myriads of bugs that were fixed in ASDF 2 that you may have to face some day: regarding safe handling of pathnames beyond the Unix model (Windows, JVM, URLs); regarding extensibility of find-system, and if Quicklisp hooks into it, potential infinite loops; regarding the ability to upgrade your ASDlite from one version to the next. etc. See the git log of asdf for so many bugs we fixed, each corresponding to some use case we hadn't considered.
I predict point 3 will bring you only sorrow, unless you effectively embrace ASDF itself via some kind of bridge. For XCVB, I chose to have ASDF interoperability by allowing XCVB builds to depend on ASDF systems and vice-versa. There may be duplication and weird interactions when some system is loaded both as an XCVB build and as an ASDF system.
I do not say that to discourage you. I hope you have fun developing and using your system. I'm just suggesting that your system will probably have little success beyond yourself. It would require tremendous amount of coding and energy to transform what you have into a "product" capable of replacing ASDF, and considering you have basically the same design, that would be for very little comparative benefit to the community.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is said that pragmatism trumps ideology in a crisis. What actually happens in a crisis, certainly in this one, is that the ruling party gets to rechristen its ideology as pragmatism. — Christopher Caldwell
Fare wrote on Mon, 23 Apr 2012 18:57:31 -0400 02:57:
F> I have added your tool to the list of non-ASDF build system at F> http://common-lisp.net/project/asdf/#what_it_is_not
Thanks you.
F> Have you looked at the other ones?
I intensively used Mark Kantrowitz's mk-defsystem a decade ago.
F> I don't see your system bringing enough new functionality F> for anyone to bother switching, much less everyone.
Yes. There is no new functionality in ASDlite except operation arguments in dependencies. But I am still uncertain about whether this brings much benefit.
F> In the end, you're about the same size as ASDF 1, F> and about the same functionality. F> You have the same configuration issue as ASDF 1. F> There are myriads of bugs that were fixed in ASDF 2 F> that you may have to face some day: regarding safe handling of pathnames beyond F> the Unix model (Windows, JVM, URLs);
It sounds strange to discover myriads of bugs in the partial sort algorithm implementation :-) Those bugs seem to originate from the multi-platform and multi-implementation nature.
I am basically developing on Windows and do not see any troubles.
F> regarding extensibility of find-system, F> and if Quicklisp hooks into it, potential infinite loops; F> regarding the ability to upgrade your ASDlite from one version to F> the next. etc. See the git log of asdf for so many bugs we fixed, F> each corresponding to some use case we hadn't considered. F> F> I predict point 3 will bring you only sorrow, F> unless you effectively embrace ASDF itself via some kind of bridge.
No sorrow. Someone else's libraries that I am using and that are equipped with ASD-files can be built fine with ASDlite. That is enough to me.
I am realize the problems you are describing and appreciate the great amount of ASDF maintenance efforts. I do not target at such an universal tool. No plans of extending ASDlite much.
F> I do not say that to discourage you. F> I hope you have fun developing and using your system.
I only needed a small library for handling module and file dependencies to inherited from. Even not related to Lisp system compile-and-load tasks.
In hope ASDF could fit, I was entirely based on ASDF 1 previously. But after I saw ASDF 2, I had declined to embed such a "heavy-weight" subsystem into my projects.
Thank you once again for the detail response. -- Sincerely, Dmitriy Ivanov lisp.ystok.ru
-
Dmitriy Ivanov -
Faré