Commit b58de273 authored by Francois-Rene Rideau's avatar Francois-Rene Rideau
Browse files

Document :if-feature. Edit away some obsolete stuff.

parent 6bb1036a
......@@ -936,7 +936,6 @@ system-option := :defsystem-depends-on system-list
module-option := :components component-list
| :serial [ t | nil ]
| :if-component-dep-fails component-dep-fail-option
option :=
| :pathname pathname-specifier
......@@ -945,6 +944,7 @@ option :=
| :explain method-form
| :output-files method-form
| :operation-done-p method-form
| :if-feature feature-expression
| :depends-on ( @var{dependency-def}* )
| :in-order-to ( @var{dependency}+ )
......@@ -978,6 +978,9 @@ method-form := (operation-name qual lambda-list @&rest body)
qual := method qualifier
component-dep-fail-option := :fail | :try-next | :ignore
feature-expression := keyword | (:and @var{feature-expression}*)
| (:or @var{feature-expression}*) | (:not @var{feature-expression})
@end example
......@@ -1032,9 +1035,10 @@ successful. Typically this is used if there are a number of systems
that, if present, could provide additional functionality, but which are
not necessary for basic function.
Currently, although it is specified to be an option only to
@code{defsystem}, this option is accepted at any component, but it probably
only makes sense at the @code{defsystem} level. Programmers are cautioned not
Currently, although it is specified to be an option only to @code{defsystem},
this option is accepted at any component, but it probably
only makes sense at the @code{defsystem} level.
Programmers are cautioned not
to use this component option except at the @code{defsystem} level, as
this anomalous behavior may be removed without warning.
......@@ -1262,11 +1266,21 @@ and @code{*load-truename*} is currently unbound
from within an editor without clobbering its source location)
@end itemize
@subsection if-component-dep-fails option
@subsection if-feature option
This option allows you to specify a feature expression to be evaluated
as if by @code{#+} to conditionally include a component in your build.
If the expression is false, the component is dropped
as well as any dependency pointing to it.
As compared to using @code{#+} which is expanded at read-time,
this allows you to have an object in your component hierarchy
that can be used for manipulations beside building your project.
This option was added in ASDF 2.27.
This option was removed in ASDF 2.27,
because its semantics was limited in purpose and dubious to explain,
and its implementation was breaking a hole into ASDF abstractions.
@subsection if-component-dep-fails option
This option was removed in ASDF 2.27.
Its semantics was limited in purpose and dubious to explain,
and its implementation was breaking a hole into the ASDF object model.
Please use the @code{if-feature} option instead.
@node Other code in .asd files, , The defsystem grammar, Defining systems with defsystem
@section Other code in .asd files
......@@ -2031,6 +2045,7 @@ are inferred to be of this type.
@item
@code{:if-component-dep-fails}
This attribute was removed in ASDF 2.27. Do not use it.
Use @code{:if-feature} instead.
@item
@code{:serial} When this attribute is set,
......@@ -3607,11 +3622,12 @@ The following issues and many others have been fixed:
@itemize
@item
The infamous TRAVERSE function has been revamped significantly,
The infamous TRAVERSE function has been revamped completely,
with many bugs squashed.
In particular, dependencies were not correctly propagated
across submodules within a system but now are.
The :version and :feature features and
across modules but now are.
Timestamps were not correctly propagated at all.
The :version and
the :force (system1 .. systemN) feature have been fixed.
@item
......@@ -4195,39 +4211,7 @@ Have a package ASDF-USER instead of all these temporary packages?
** proclamations probably aren't
** (stuff that might happen later)
*** Propagation of the @code{:force} option.
``I notice that
@code{(asdf:compile-system :araneida :force t)}
also forces compilation of every other system
the @code{:araneida} system depends on.
This is rarely useful to me;
usually, when I want to force recompilation
of something more than a single source file,
I want to recompile only one system.
So it would be more useful to have @code{make-sub-operation}
refuse to propagate @code{:force t} to other systems, and
propagate only something like @code{:force :recursively}.
Ideally what we actually want is some kind of criterion that says
to which systems (and which operations) a @code{:force} switch will propagate.
The problem is perhaps that ``force'' is a pretty meaningless concept.
How obvious is it that @code{load :force t} should force @emph{compilation}?
But we don't really have the right dependency setup
for the user to compile @code{:force t} and expect it to work
(files will not be loaded after compilation, so the compile
environment for subsequent files will be emptier than it needs to be)
What does the user actually want to do when he forces?
Usually, for me, update for use with a new version of the Lisp compiler.
Perhaps for recovery when he suspects that something has gone wrong.
Or else when he's changed compilation options or configuration
in some way that's not reflected in the dependency graph.
** A revert function
Other possible interface: have a ``revert'' function akin to @code{make clean}.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment