1
0
Fork 0
cl-sites/asdf.common-lisp.dev/asdf/Common-attributes-of-components.html
2023-11-12 11:34:18 +01:00

317 lines
14 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Created by GNU Texinfo 6.8, https://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<!-- This manual describes ASDF, a system definition facility
for Common Lisp programs and libraries.
You can find the latest version of this manual at
https://common-lisp.net/project/asdf/asdf.html.
ASDF Copyright (C) 2001-2019 Daniel Barlow and contributors.
This manual Copyright (C) 2001-2019 Daniel Barlow and contributors.
This manual revised (C) 2009-2019 Robert P. Goldman and Francois-Rene Rideau.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-->
<title>Common attributes of components (ASDF Manual)</title>
<meta name="description" content="Common attributes of components (ASDF Manual)">
<meta name="keywords" content="Common attributes of components (ASDF Manual)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta name="viewport" content="width=device-width,initial-scale=1">
<link href="index.html" rel="start" title="Top">
<link href="Concept-Index.html" rel="index" title="Concept Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="Components.html" rel="up" title="Components">
<link href="Pre_002ddefined-subclasses-of-component.html" rel="next" title="Pre-defined subclasses of component">
<link href="Components.html" rel="prev" title="Components">
<style type="text/css">
<!--
a.copiable-anchor {visibility: hidden; text-decoration: none; line-height: 0em}
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
span:hover a.copiable-anchor {visibility: visible}
ul.no-bullet {list-style: none}
-->
</style>
</head>
<body lang="en">
<div class="subsection" id="Common-attributes-of-components">
<div class="header">
<p>
Next: <a href="Pre_002ddefined-subclasses-of-component.html" accesskey="n" rel="next">Pre-defined subclasses of component</a>, Previous: <a href="Components.html" accesskey="p" rel="prev">Components</a>, Up: <a href="Components.html" accesskey="u" rel="up">Components</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<span id="Common-attributes-of-components-1"></span><h4 class="subsection">7.2.1 Common attributes of components</h4>
<p>All components, regardless of type, have the following attributes.
All attributes except <code>name</code> are optional.
</p>
<ul class="section-toc">
<li><a href="Common-attributes-of-components.html#Name" accesskey="1">Name</a></li>
<li><a href="Common-attributes-of-components.html#Version-identifier" accesskey="2">Version identifier</a></li>
<li><a href="Common-attributes-of-components.html#Required-features" accesskey="3">Required features</a></li>
<li><a href="Common-attributes-of-components.html#Dependencies-1" accesskey="4">Dependencies</a></li>
<li><a href="Common-attributes-of-components.html#pathname" accesskey="5">pathname</a></li>
<li><a href="Common-attributes-of-components.html#Properties" accesskey="6">Properties</a></li>
</ul>
<div class="subsubsection" id="Name">
<h4 class="subsubsection">7.2.1.1 Name</h4>
<span id="index-coerce_002dname-2"></span>
<p>A component name is a string or a symbol.
If a symbol, its name is taken and lowercased. This translation is
performed by the exported function <code>coerce-name</code>.
</p>
<p>Unless overridden by a <code>:pathname</code> attribute,
the name will be interpreted as a pathname specifier according
to a Unix-style syntax.
See <a href="The-defsystem-grammar.html#Pathname-specifiers">Pathname specifiers</a>.
</p>
</div>
<div class="subsubsection" id="Version-identifier">
<h4 class="subsubsection">7.2.1.2 Version identifier</h4>
<span id="index-version_002dsatisfies"></span>
<span id="index-_003aversion-2"></span>
<p>This optional attribute specifies a version for the current component.
The version should typically be a string of integers separated by dots,
for example &lsquo;<samp>1.0.11</samp>&rsquo;. See <a href="The-defsystem-grammar.html#Version-specifiers">Version specifiers</a>.
</p>
<p>A version may then be queried by the generic function <code>version-satisfies</code>,
to see if <code>:version</code> dependencies are satisfied,
and when specifying dependencies, a constraint of minimal version to satisfy
can be specified using e.g. <code>(:version &quot;mydepname&quot; &quot;1.0.11&quot;)</code>.
</p>
<p>Note that in the wild, we typically see version numbering
only on components of type <code>system</code>.
Presumably it is much less useful within a given system,
wherein the library author is responsible to keep the various files in synch.
</p>
</div>
<div class="subsubsection" id="Required-features">
<h4 class="subsubsection">7.2.1.3 Required features</h4>
<span id="required_002dfeatures"></span>
<p>Traditionally defsystem users have used <code>#+</code> reader conditionals
to include or exclude specific per-implementation files.
For example, CFFI, the portable C foreign function interface contained
lines like:
</p><div class="example lisp">
<pre class="lisp"> #+sbcl (:file &quot;cffi-sbcl&quot;)
</pre></div>
<p>An unfortunate side effect of this approach is that no single
implementation can read the entire system.
This causes problems if, for example, one wished to design an <code>archive-op</code>
that would create an archive file containing all the sources, since
for example the file <code>cffi-sbcl.lisp</code> above would be invisible when
running the <code>archive-op</code> on any implementation other than SBCL.
</p>
<p>Starting with ASDF 3,
components may therefore have an <code>:if-feature</code> option.
The value of this option should be
a feature expression using the same syntax as <code>#+</code> does.
If that feature expression evaluates to false, any reference to the component will be ignored
during compilation, loading and/or linking.
Since the expression is read by the normal reader,
you must explicitly prefix your symbols with <code>:</code> so they be read as keywords;
this is as contrasted with the <code>#+</code> syntax
that implicitly reads symbols in the keyword package by default.
</p>
<p>For instance, <code>:if-feature (:and :x86 (:or :sbcl :cmu :scl))</code> specifies that
the given component is only to be compiled and loaded
when the implementation is SBCL, CMUCL or Scieneer CL on an x86 machine.
You cannot write it as <code>:if-feature (and x86 (or sbcl cmu scl))</code>
since the symbols would not be read as keywords.
</p>
<p>See <a href="The-defsystem-grammar.html#if_002dfeature-option">if-feature option</a>.
</p>
</div>
<div class="subsubsection" id="Dependencies-1">
<h4 class="subsubsection">7.2.1.4 Dependencies</h4>
<p>This attribute specifies dependencies of the component on its siblings.
It is optional but often necessary.
</p>
<p>There is an excitingly complicated relationship between the initarg
and the method that you use to ask about dependencies
</p>
<p>Dependencies are between (operation component) pairs.
In your initargs for the component, you can say
</p>
<div class="example lisp">
<pre class="lisp">:in-order-to ((compile-op (load-op &quot;a&quot; &quot;b&quot;) (compile-op &quot;c&quot;))
(load-op (load-op &quot;foo&quot;)))
</pre></div>
<p>This means the following things:
</p><ul>
<li> before performing compile-op on this component, we must perform
load-op on <var>a</var> and <var>b</var>, and compile-op on <var>c</var>,
</li><li> before performing <code>load-op</code>, we have to load <var>foo</var>
</li></ul>
<p>The syntax is approximately
</p>
<pre class="verbatim">(this-op @{(other-op required-components)@}+)
simple-component-name := string
| symbol
required-components := simple-component-name
| (required-components required-components)
component-name := simple-component-name
| (:version simple-component-name minimum-version-object)
</pre>
<p>Side note:
</p>
<p>This is on a par with what ACL defsystem does.
mk-defsystem is less general: it has an implied dependency
</p>
<pre class="verbatim"> for all source file x, (load x) depends on (compile x)
</pre>
<p>and using a <code>:depends-on</code> argument to say that <var>b</var> depends on
<var>a</var> <em>actually</em> means that
</p>
<pre class="verbatim"> (compile b) depends on (load a)
</pre>
<p>This is insufficient for e.g. the McCLIM system, which requires that
all the files are loaded before any of them can be compiled ]
</p>
<p>End side note
</p>
<p>In ASDF, the dependency information for a given component and operation
can be queried using <code>(component-depends-on operation component)</code>,
which returns a list
</p>
<div class="example lisp">
<pre class="lisp">((load-op &quot;a&quot;) (load-op &quot;b&quot;) (compile-op &quot;c&quot;) ...)
</pre></div>
<p><code>component-depends-on</code> can be subclassed for more specific
component/operation types: these need to <code>(call-next-method)</code>
and append the answer to their dependency, unless
they have a good reason for completely overriding the default dependencies.
</p>
<p>If it weren&rsquo;t for CLISP, we&rsquo;d be using <code>LIST</code> method
combination to do this transparently.
But, we need to support CLISP.
If you have the time for some CLISP hacking,
I&rsquo;m sure they&rsquo;d welcome your fixes.
</p>
<p>A minimal version can be specified for a component you depend on
(typically another system), by specifying <code>(:version &quot;other-system&quot; &quot;1.2.3&quot;)</code>
instead of simply <code>&quot;other-system&quot;</code> as the dependency.
See the discussion of the semantics of <code>:version</code>
in the defsystem grammar.
</p>
</div>
<div class="subsubsection" id="pathname">
<h4 class="subsubsection">7.2.1.5 pathname</h4>
<p>This attribute is optional and if absent (which is the usual case),
the component name will be used.
</p>
<p>See <a href="The-defsystem-grammar.html#Pathname-specifiers">Pathname specifiers</a>,
for an explanation of how this attribute is interpreted.
</p>
<p>Note that the <code>defsystem</code> macro (used to create a &ldquo;top-level&rdquo; system)
does additional processing to set the filesystem location of
the top component in that system.
This is detailed elsewhere. See <a href="Defining-systems-with-defsystem.html">Defining systems with defsystem</a>.
</p>
<p>To find the CL pathname corresponding to a component, use
</p>
<dl class="def">
<dt id="index-component_002dpathname"><span class="category">Function: </span><span><strong>component-pathname</strong> <em>component</em><a href='Common-attributes-of-components.html#index-component_002dpathname' class='copiable-anchor'> &para;</a></span></dt>
<dd><p>Returns the pathname corresponding to <var>component</var>. For components
such as source files, this will be a filename pathname. For example:
</p>
<div class="example lisp">
<pre class="lisp">CL-USER&gt; (asdf:component-pathname (asdf:find-system &quot;xmls&quot;))
#P&quot;/Users/rpg/lisp/xmls/&quot;
</pre></div>
<p>and
</p>
<div class="example lisp">
<pre class="lisp">CL-USER&gt; (asdf:component-pathname
(asdf:find-component
(asdf:find-system &quot;xmls&quot;) &quot;xmls&quot;))
#P&quot;/Users/rpg/lisp/xmls/xmls.lisp&quot;
</pre></div>
</dd></dl>
</div>
<div class="subsubsection" id="Properties">
<h4 class="subsubsection">7.2.1.6 Properties</h4>
<p>This attribute is optional.
</p>
<p>Packaging systems often require information about files or systems
in addition to that specified by ASDF&rsquo;s pre-defined component attributes.
Programs that create vendor packages out of ASDF systems therefore
have to create &ldquo;placeholder&rdquo; information to satisfy these systems.
Sometimes the creator of an ASDF system may know the additional
information and wish to provide it directly.
</p>
<p><code>(component-property component property-name)</code> and
associated <code>setf</code> method will allow
the programmatic update of this information.
Property names are compared as if by <code>EQL</code>,
so use symbols or keywords or something.
</p>
</div>
</div>
<hr>
<div class="header">
<p>
Next: <a href="Pre_002ddefined-subclasses-of-component.html">Pre-defined subclasses of component</a>, Previous: <a href="Components.html">Components</a>, Up: <a href="Components.html">Components</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html" title="Index" rel="index">Index</a>]</p>
</div>
</body>
</html>