Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
A
asdf
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Didier Verna
asdf
Commits
a9ff4e6f
Commit
a9ff4e6f
authored
10 years ago
by
Francois-Rene Rideau
Browse files
Options
Downloads
Patches
Plain Diff
Manual: document primary system names (in defun find-system, meh).
parent
567f591a
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/asdf.texinfo
+62
-17
62 additions, 17 deletions
doc/asdf.texinfo
with
62 additions
and
17 deletions
doc/asdf.texinfo
+
62
−
17
View file @
a9ff4e6f
...
...
@@ -2390,27 +2390,69 @@ of the system in memory
@cindex ASDF-USER package
When system definitions are loaded from @file
{
.asd
}
files,
they are implicitly loaded into the @code
{
ASDF-USER
}
package, which uses
@code
{
ASDF
}
.
The programmer is also recommended to
include @code
{
defpackage
}
and @code
{
in-package
}
forms
in his system definition files, however, so that they
will behave identically if loaded manually for development or debugging.
One should define one's own package (typically using @code
{
ASDF
}
and
@code
{
COMMON-LISP
}
) if adding new classes, methods, etc., in order that
different systems do not overwrite each others' extensions.
they are implicitly loaded into the @code
{
ASDF-USER
}
package,
which uses @code
{
ASDF
}
, @code
{
UIOP
}
and @code
{
UIOP/COMMON-LISP
}
@footnote
{
Note that between releases 2.27 and 3.0.3, only @code
{
UIOP/PACKAGE
}
,
not all of @code
{
UIOP
}
, was used; if you want your code to work
with releases earlier than 3.1.2, you may have to explicitly define a package
that uses @code
{
UIOP
}
, or use proper package prefix to your symbols, as in
@code
{
uiop:version<
}
.
}
Programmers who do anything non-trivial in a @file
{
.asd
}
file,
such as defining new variables, functions or classes,
should include @code
{
defpackage
}
and @code
{
in-package
}
forms in this file,
so they will not overwrite each others' extensions.
Such forms might also help the files behave identically
if loaded manually with @code
{
cl:load
}
for development or debugging,
though we recommend you use the function @code
{
asdf::load-asd
}
instead,
which the @code
{
slime-asdf
}
contrib knows about.
The default value of @code
{
*system-definition-search-functions*
}
is a list of t
wo
functions.
is a list of t
hree
functions.
The first function looks in each of the directories given
by evaluating members of @code
{
*central-registry*
}
for a file whose name is the name of the system and whose type is @file
{
asd
}
.
T
he first such file is returned,
for a file whose name is the name of the system and whose type is @file
{
asd
}
;
t
he first such file is returned,
whether or not it turns out to actually define the appropriate system.
The second function does something similar,
for the directories specified in the @code
{
source-registry
}
.
for the directories specified in the @code
{
source-registry
}
,
but searches the filesystem only once and caches its results.
The third function makes the @code
{
package-inferred-system
}
extension work,
@pxref
{
The package-inferred-system extension
}
.
Hence, it is strongly advised to define a system
@var
{
foo
}
in the corresponding file @var
{
foo.asd
}
.
@var
{
foo
}
in a corresponding file @file
{
foo.asd
}
that will be in a directory included
in the central registry or source registry configuration.
Because it is often useful to define multiple systems in a same file,
but ASDF can only locate a system's definition file based on the system name,
ASDF 3 also supports the convention whereby a file @file
{
foo.asd
}
can contain
secondary systems named @var
{
foo/bar
}
, @var
{
foo/baz
}
, @var
{
foo/quux
}
, etc.,
in addition to the primary system named @var
{
foo
}
.
The first component of a system name
when separated by slash characters @code
{
/
}
is called the primary name of a system,
as extracted by function @code
{
asdf::primary-system-name
}
;
when ASDF 3 is told to find a system whose name has a slash,
it will first attempt to load the corresponding primary system,
and will thus see any such definitions, and/or any
definition of a @code
{
package-inferred-system
}
.@footnote
{
ASDF 2.26 and earlier versions however
do not actively support this primary system name convention,
and you will have to explicitly load @file
{
foo.asd
}
before you can use system @var
{
foo/bar
}
defined therein,
e.g. using @code
{
(asdf:find-system "foo")
}
.
We do not support ASDF 2, and recommend that you should upgrade to ASDF 3.
}
If your file @file
{
foo.asd
}
also defines systems
that do not follow this convention, e.g., a system named @var
{
foo-test
}
,
ASDF will not be able to automatically locate a definition for these systems,
and will only see their definition
if you explicitly find or load the primary system
using e.g. @code
{
(asdf:find-system "foo")
}
before you try to use them.
We strongly recommend against this practice,
though it is currently supported for backward compatibility.
@end defun
@defun locate-system name
...
...
@@ -2419,17 +2461,20 @@ This function should typically @emph{not} be invoked directly. It is
exported as part of the API only for programmers who wish to provide
their own @code
{
*system-definition-search-functions*
}
.
Given a system @var
{
name
}
designator, try to locate where to load the system from.
Given a system @var
{
name
}
designator,
try to locate where to load the system from.
Returns five values: @var
{
foundp
}
, @var
{
found-system
}
, @var
{
pathname
}
,
@var
{
previous
}
, and @var
{
previous-time
}
.
@var
{
foundp
}
is true when a system was found,
either a new as yet unregistered one, or a previously registered one.
@var
{
found-system
}
when not null is a @code
{
system
}
object that may be @code
{
register-system
}
'ed.
@var
{
found-system
}
when not null is
a @code
{
system
}
object that may be @code
{
register-system
}
'ed.
@var
{
pathname
}
when not null is a path from which to load the system,
either associated with @var
{
found-system
}
, or with the @var
{
previous
}
system.
@var
{
previous
}
when not null is a previously loaded @code
{
system
}
object
of the same name.
@var
{
previous-time
}
when not null is the time at which the @var
{
previous
}
system was loaded.
@var
{
previous-time
}
when not null is
the time at which the @var
{
previous
}
system was loaded.
@end defun
@defun find-component base path
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment