On Sat, 2010-11-20 at 02:10 -0500, Faré wrote:
On 19 November 2010 16:20, Krzysztof Drewniak krzysdrewniak@gmail.com wrote:
2- It's not clear that anyone would use it. What problem are you solving? How does it help?
If solves the problem of not having a standard way to "install" a common lisp library. See my other reply for details.
There is nothing whatsoever to install in a CL library. FASLs? They vary from implementation to implementation, and even in a given implementation, depending on OPTIMIZE settings, *features* and possibly more (code coverage, grovelling, some lisp-in-lisp compilation for e.g. continuations, etc.)
And what the hell do you configuration settings correspond to? Yet another layer of bureaucracy between the user and the above-mentionned settings and features?
As fetching dependencies is clearly not in scope for asdf, dependencies will be checked to see if they are loadable in the beginning of install-op, and if they are not present, a helpful error is signalled.
What when a dependency is compiled with a different settings, entailing different semantics for the final "library"?
4- How do you distinguish between fasls compiled with different options.
If config.asdf is modified, fasls are recompiled. If two different source trees of the same system are installed, they will vertanly not be installed in the same place, thuse distinguishing the fasls.
That's not the question asked. How do you make sure there is no unwanted sharing between two "versions" of the fasls for a same library as installed in the same tree?
Also, if you are using different "trees" of libraries, either use different :registry files, or don't use these operations.
That's not the question asked. If you have different trees, you don't need to distinguish configurations. But usually you don't.
Or what the hell are your "configurations" useful for?
To clarify something in advance, config-get does NOT require you to have used install-op, you could have done the installation manually.
Your whole proposal sounds like more bureaucracy that doesn't actually help anyone get anything done but adds more work for everyone. I say emphatically NO to any of it.
Please provide a use case — we'll tell you how to do without it.
There are ways that a build system could benefit from understanding multiple "configurations" of a same tree, but ASDF will never ever possibly do that, since that would require major refactoring and breaking backward compatibility. If you're interested in such things, consider hacking XCVB instead.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Big Business has to *sell* the Vietnam War to you. Big Government can just draft your ass and ship you overseas under threat of imprisonment and/or death. Now, which one is better again? — rho@netdoor.com
Never mind. asdf-install already solved most of the problem.