[asdf-devel] Mistake (?) in grammar of defsystem
I see that the grammar of dependencies in the manual specifies that :version appears as a keyword symbol, but feature appears as *not* a keyword symbol. Is this a documentation bug? I think so, but you know the actual execution semantics better. If it is a doc bug, I'll fix it right away. thx, r
Another documentation mismatch. We have a test system that looks like this: (defsystem :test-asdf/test-module-depend :depends-on ((:feature :sbcl (:require :sb-posix)) (:feature :allegro (:require "osi"))) :components ...) But the grammar says: (feature FEATURE-NAME) What are the semantics of this compound :FEATURE dependency? Looks like it's some sort of conditional, and I don't see any documentation for :REQUIRE in the manual. I will fix these, as appropriate, since I'm already expanding the manual. Thanks, r
On Sat, Feb 22, 2014 at 2:56 PM, Robert P. Goldman <rpgoldman@sift.info> wrote:
I see that the grammar of dependencies in the manual specifies that :version appears as a keyword symbol, but feature appears as *not* a keyword symbol.
Is this a documentation bug? I think so, but you know the actual execution semantics better.
If it is a doc bug, I'll fix it right away.
Beware that there are two "feature" features 1- In a depends-on specification, as defined in find-component.lisp, you can write (:feature <feature-expression> <dependency-spec>), where the dependency link is valid if <feature-expression> is true as per featurep. This feature was hidden in the ASDF 1 code, but I'm not convinced this feature worked before ASDF 3, when I fixed it for good. Therefore, I'm pretty sure noone uses this feature. 2- In a component-depends-on method or in-order-to specification, (feature foo) instead of (operation components...) then a missing dependency error is raised. This was used in conjunction with the ill-designed :if-component-dep-fails feature to provide conditional dependency. This later feature was removed (minus a thin partial compatibility layer for old SBCLs), because it was not compatible with the fixed ASDF3 dependency model. I suggest both features should probably be deprecated and removed, and the :if-feature feature introduced in ASDF3, that actually works. If any system anywhere uses these features, they should be fixed ASAP. We should probably run a cl-test-grid test with these features disabled. See patch attached. NB: I obviously cannot commit this patch unless the maintainer wants me to. Robert, this baby is yours. The diff above also doesn't remove the misfeatures from the tests and documentation. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The program isn't debugged until the last user is dead.
Thanks, Faré. Quick follow up: is there any construct that has semantics like "If this feature is not in features, fail"? On February 22, 2014 4:22:17 PM CST, "Faré" <fare@tunes.org> wrote:
On Sat, Feb 22, 2014 at 2:56 PM, Robert P. Goldman <rpgoldman@sift.info> wrote:
I see that the grammar of dependencies in the manual specifies that :version appears as a keyword symbol, but feature appears as *not* a keyword symbol.
Is this a documentation bug? I think so, but you know the actual execution semantics better.
If it is a doc bug, I'll fix it right away.
Beware that there are two "feature" features
1- In a depends-on specification, as defined in find-component.lisp, you can write (:feature <feature-expression> <dependency-spec>), where the dependency link is valid if <feature-expression> is true as per featurep. This feature was hidden in the ASDF 1 code, but I'm not convinced this feature worked before ASDF 3, when I fixed it for good. Therefore, I'm pretty sure noone uses this feature.
2- In a component-depends-on method or in-order-to specification, (feature foo) instead of (operation components...) then a missing dependency error is raised. This was used in conjunction with the ill-designed :if-component-dep-fails feature to provide conditional dependency. This later feature was removed (minus a thin partial compatibility layer for old SBCLs), because it was not compatible with the fixed ASDF3 dependency model.
I suggest both features should probably be deprecated and removed, and the :if-feature feature introduced in ASDF3, that actually works. If any system anywhere uses these features, they should be fixed ASAP.
We should probably run a cl-test-grid test with these features disabled. See patch attached.
NB: I obviously cannot commit this patch unless the maintainer wants me to. Robert, this baby is yours. The diff above also doesn't remove the misfeatures from the tests and documentation.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The program isn't debugged until the last user is dead.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sat, Feb 22, 2014 at 5:53 PM, Robert P. Goldman <rpgoldman@sift.net> wrote:
Thanks, Faré. Quick follow up: is there any construct that has semantics like "If this feature is not in features, fail"?
That's what the (feature <feature-expression>) component-depends-on/in-order-to feature does. Do you think it's useful? On the other hand, I realize that, though it's never worked and is probably never used, the (:feature <feature-expression> <dependency-spec>) feature is conceivably useful for conditional dependencies of a system, as in this example from test-asdf.asd: (defsystem :test-asdf/test-module-depend :depends-on ((:feature :sbcl (:require :sb-posix)) (:feature :allegro (:require "osi"))) ...) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org How can you find a person who loves you the way you are, if you constantly lie about who you are?
Here's an improved diff, that keeps and properly documents the (:feature <feature-expression> <dependency-def>) dependency-def, and eliminates the (feature <feature-expression>) requirement (using names from the grammar). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The secret of survival is: Always expect the unexpected. — Dr. Who
Thanks. This helps a lot. Follow-up question: :if-feature really doesn't make sense at the system level, does it? The grammar allows that, but it seems silly there. Am I wrong about this? I will add an example of suggested use of :IF-FEATURE to the manual. Best, r -- Robert P. Goldman Staff Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman@SIFT.net
On Sun, Feb 23, 2014 at 11:38 AM, Robert Goldman <rpgoldman@sift.net> wrote:
Thanks. This helps a lot. Follow-up question: :if-feature really doesn't make sense at the system level, does it? The grammar allows that, but it seems silly there. Am I wrong about this?
I will add an example of suggested use of :IF-FEATURE to the manual.
Actually, I hadn't thought of that, but the :if-feature might make sense at the system level indeed. For instance, sb-grovel and other sbcl extensions could be :if-feature :sbcl, whereas my single-threaded-ccl could be :if-feature :ccl. Actually, I just did that to the latter! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Please leave the State in the toilets where you found it.
participants (4)
-
Faré -
Robert Goldman -
Robert P. Goldman -
Robert P. Goldman