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