On 5/17/16 May 17 -8:47 AM, Faré wrote: > On Tue, May 17, 2016 at 9:39 AM, Didier Verna <did...@lrde.epita.fr> wrote: >> Stelian Ionescu wrote: >> >>> #-feature >>> (error "FEATURE missing") >>> >>> at toplevel, so you get an error on reading the .asd file. >> >> Of course. I said a "declarative way" within the system itself tho ;-) >> > I strongly recommend against erroring in the .asd file itself based on > the implementation, because that hinders cross-compilation.
IIUC what this boils down to is a preference for failing to *operate* on the system, rather than failing to parse the system definition. Correct? [As an aside, there may be a separate bug: when I tried to load DecLt into ACL, the loading *succeeded*, but the contents of the decLt "core" subsystem failed to be loaded. So I believe there may be an oddity in the way ASDF is handling these "failed" :feature dependencies. I will try to replicate and provide a minimal test case.] > > The traditional solution is to load a file that fails. > i.e. create a file unsupported-implementation.lisp that > has an (error ...) form and in your asd file, use a component > (:file "unsupported-implementation" :if-feature (:not :sbcl)) I would prefer that we provide a more readable version of this. I think we could readily add (:depends-on (:essential-feature :sbcl)) As I said earlier, the "bogus file" solution seems to me unpleasantly indirect, because then the poor reader must grovel over "unsupported-implementation" to see what will happen if one tries to load it, when the intent is simply to say "this won't work unless you are on SBCL." I believe we could provide this with the semantics you propose (fail on operation, not on loading the system definition). > And yes, I probably should have called it :when-feature instead of > :if-feature. My bad. If you think that's worth it, we can add the new > name now and remove the old name in 2 years. > > PS: Robert, I pushed a tiny tweak to the documentation. Thanks, I'll pull and have a look now. best, r
