Newer
Older
Robert P. Goldman
committed
@node Controlling where ASDF saves compiled files, Special variables, The object model of asdf, Top
@comment node-name, next, previous, up
@chapter Controlling where ASDF saves compiled files
@cindex ASDF-binary-locations
Each Common Lisp implementation has its own format for
compiled files (fasls for short). If you use multiple
implementations (or multiple versions of the same
implementation), you'll soon find your source directories
littered with various `DFSL`s, `FASL`s, `CFSL`s and so on.
Worse yet, some implementations use the same file extension
or change formats from version to version which means that
you'll have to recompile binaries as you switch from one
implementation to the next.
As of version 1.365, ASDF includes @emph{ASDF-binary-locations} to
mitigate the problem.
@section Default locations
@vindex *enable-asdf-binary-locations*
Robert P. Goldman
committed
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
@vindex *centralize-lisp-binaries*
@vindex *default-toplevel-directory*
@vindex *include-per-user-information*
@vindex *map-all-source-files*
@vindex *source-to-target-mappings*
@findex output-files-for-system-and-operation
The default binary location for each Lisp implementation is a
subdirectory of each source directory. To account for different Lisps,
Operating Systems, Implementation versions, and so on, ASDF borrows code
from SLIME to create reasonable custom directory names. Here are
some examples:
@itemize
@item SBCL, version 1.0 on Mac OS X for intel: @code{sbcl-1.0-darwin-x86}
@item Franz Allegro, version 8.0, ANSI Common Lisp: @code{allegro-8.0a-macosx-x86}
@item Franz Allegro, version 8.1, Modern (case sensitive) Common Lisp: @code{allegro-8.1m-macosx-x86}
@end itemize
If you want to keep compiled files out of the source tree entirely, use
@code{*centralize-lisp-binaries*} to put compiled files into
sub-directories of a single central location (see below).
Here is a summary of the variables that control ASDF's source-to-binary
mappings. All of them are in the ASDF package, so must be set
@emph{after} loading ASDF.
Robert P. Goldman
committed
@itemize
@item @code{*enable-asdf-binary-locations*}:
Robert P. Goldman
committed
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
If false, then ASDF will place binaries in the same directory as the
source. If true, then ASDF will move the binaries using the rest of
the configuration. Defaults to @code{nil}.
@item @code{*centralize-lisp-binaries*}: If true, compiled lisp files
without an explicit mapping (see @code{*source-to-target-mappings*})
will be placed in subdirectories of
@code{*default-toplevel-directory*}. If false, then compiled lisp
files without an explicit mapping will be placed in subdirectories
of their sources. Defaults to @code{nil}.
@item @code{*default-toplevel-directory*}. If
@code{*centralize-lisp-binaries*} is true, then compiled lisp files
without an explicit mapping (see @code{*source-to-target-mappings*})
will be placed in subdirectories of
@code{*default-toplevel-directory*}. Defaults to a sub-directory
named `.fasls` in the current user's home directory.
@item @code{*include-per-user-information*}. specifies whether or not
to include user information in the directory. Only used when
@code{*centralize-lisp-binaries*} is true. Defaults to @code{nil}.
@item @code{*map-all-source-files*}. If true, then all source files
will be mapped by ASDF. If @code{nil}, then only Common Lisp Source
Files (i.e., instances of cl-source-file or its subclasses) will
be. Defaults to @code{nil}.
@item @code{*source-to-target-mappings*}. This specifies mappings
from source to target. If the target is nil, then it
means to *not* map the source to anything. I.e., to leave
it as is. This has the effect of turning off
ASDF-Binary-Locations for the given source directory. The
default depends on the Lisp implementation.
@end itemize
These variables are used by
@code{output-files-for-system-and-operation} to determine where to
place a source file's binary. You can further customize asdf-binary-locations
by writing additional methods on the generic function
@code{output-files-for-system-and-operation}.
@c See the [manual][binary-locations] for more details.
@subsection Notes and Issues
SBCL ships with several included ASDF libraries which used to confuse
ABL because it would try to recompile the FASLs and then run into
directory permission problems. ASDF knows about these and uses a mapping
like @file{/usr/local/lib/sbcl} to @code{nil} so that the FASLs are not
relocated.
@node Special variables, Error handling, Controlling where ASDF saves compiled files, Top
@comment node-name, next, previous, up
@chapter Special variables
@node Error handling, Compilation error and warning handling, Special variables, Top
@comment node-name, next, previous, up
@chapter Error handling
@findex SYSTEM-DEFINITION-ERROR
@findex OPERATION-ERROR
It is an error to define a system incorrectly: an implementation may
detect this and signal a generalised instance of
@code{SYSTEM-DEFINITION-ERROR}.
Operations may go wrong (for example when source files contain
errors). These are signalled using generalised instances of
@code{OPERATION-ERROR}.
@node Compilation error and warning handling, Miscellaneous additional functionality, Error handling, Top
@comment node-name, next, previous, up
@chapter Compilation error and warning handling
@vindex *compile-file-warnings-behaviour*
@vindex *compile-file-errors-behavior*
ASDF checks for warnings and errors when a file is compiled. The
variables @code{*compile-file-warnings-behaviour*} and
@code{*compile-file-errors-behavior*} controls the handling of any
such events. The valid values for these variables are @code{:error},
@code{:warn}, and @code{:ignore}.
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
@node Miscellaneous additional functionality, Getting the latest version, Compilation error and warning handling, Top
@comment node-name, next, previous, up
@chapter Additional Functionality
ASDF includes several additional features that are generally
useful for system definition and development. These include:
@enumerate
@item
system-relative-pathname
It's often handy to locate a file relative to some system. The system-relative-pathname function meets this need. It takes two arguments: the name of a system and a relative pathname. It returns a pathname built from the
location of the system's source file and the relative pathname. For example
@lisp
> (asdf:system-relative-pathname 'cl-ppcre "regex.data")
#P"/repository/other/cl-ppcre/regex.data"
@end lisp
@end enumerate
@node Getting the latest version, TODO list, Miscellaneous additional functionality, Top
@comment node-name, next, previous, up
@chapter Getting the latest version
Robert P. Goldman
committed
@c FIXME: Need to revise this to give information about the git repository.
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
@enumerate
@item
Decide which version you want. HEAD is the newest version and
usually OK, whereas RELEASE is for cautious people (e.g. who already
have systems using asdf that they don't want broken), a slightly older
version about which none of the HEAD users have complained.
@item
Check it out from sourceforge cCLan CVS:
@kbd{cvs -d:pserver:anonymous@@cvs.cclan.sourceforge.net:/cvsroot/cclan login}
(no password: just press @key{Enter})
@kbd{cvs -z3 -d:pserver:anonymous@@cvs.cclan.sourceforge.net:/cvsroot/cclan co -r RELEASE asdf}
or for the bleeding edge, instead
@kbd{cvs -z3 -d:pserver:anonymous@@cvs.cclan.sourceforge.net:/cvsroot/cclan co -A asdf}
@end enumerate
If you are tracking the bleeding edge, you may want to subscribe to
the cclan-commits mailing list (see
@url{http://sourceforge.net/mail/?group_id=28536}) to receive commit
messages and diffs whenever changes are made.
For more CVS information, look at
@url{http://sourceforge.net/cvs/?group_id=28536}.
@node TODO list, missing bits in implementation, Getting the latest version, Top
@comment node-name, next, previous, up
@chapter TODO list
* Outstanding spec questions, things to add
** packaging systems
*** manual page component?
** style guide for .asd files
You should either use keywords or be careful with the package that you
evaluate defsystem forms in. Otherwise (defsystem partition ...)
being read in the cl-user package will intern a cl-user:partition
symbol, which will then collide with the partition:partition symbol.
Actually there's a hairier packages problem to think about too.
in-order-to is not a keyword: if you read defsystem forms in a package
that doesn't use ASDF, odd things might happen
** extending defsystem with new options
You might not want to write a whole parser, but just to add options to
the existing syntax. Reinstate parse-option or something akin
** document all the error classes
** what to do with compile-file failure
Should check the primary return value from compile-file and see if
that gets us any closer to a sensible error handling strategy
** foreign files
lift unix-dso stuff from db-sockets
** Diagnostics
A ``dry run'' of an operation can be made with the following form:
@lisp
(traverse (make-instance '<operation-name>)
(find-system <system-name>)
'explain)
@end lisp
This uses unexported symbols. What would be a nice interface for this
functionality?
@node missing bits in implementation, Inspiration, TODO list, Top
@comment node-name, next, previous, up
@chapter missing bits in implementation
** all of the above
** reuse the same scratch package whenever a system is reloaded from disk
** rules for system pathname defaulting are not yet implemented properly
** proclamations probably aren't
** when a system is reloaded with fewer components than it previously
had, odd things happen
we should do something inventive when processing a defsystem form,
like take the list of kids and setf the slot to nil, then transfer
children from old to new list as they're found
** traverse may become a normal function
If you're defining methods on traverse, speak up.
** a lot of load-op methods can be rewritten to use input-files
so should be.
** (stuff that might happen later)
*** david lichteblau's patch for symlink resolution?
*** Propagation of the :force option. ``I notice that
(oos 'compile-op :araneida :force t)
also forces compilation of every other system the :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
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.
Other possible interface: have a 'revert' function akin to 'make clean'
@lisp
(asdf:revert 'asdf:compile-op 'araneida)
@end lisp
would delete any files produced by 'compile-op 'araneida. Of course, it
wouldn't be able to do much about stuff in the image itself.
How would this work?
traverse
There's a difference between a module's dependencies (peers) and its
components (children). Perhaps there's a similar difference in
operations? For example, @code{(load "use") depends-on (load "macros")} is a
peer, whereas @code{(load "use") depends-on (compile "use")} is more of a
`subservient' relationship.
@node Inspiration, Concept Index, missing bits in implementation, Top
@comment node-name, next, previous, up
@chapter Inspiration
@section mk-defsystem (defsystem-3.x)
We aim to solve basically the same problems as mk-defsystem does.
However, our architecture for extensibility better exploits CL
language features (and is documented), and we intend to be portable
rather than just widely-ported. No slight on the mk-defsystem authors
and maintainers is intended here; that implementation has the
unenviable task of supporting pre-ANSI implementations, which is
no longer necessary.
The surface defsystem syntax of asdf is more-or-less compatible with
mk-defsystem, except that we do not support the @code{source-foo} and
@code{binary-foo} prefixes for separating source and binary files, and
we advise the removal of all options to specify pathnames.
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
The mk-defsystem code for topologically sorting a module's dependency
list was very useful.
@section defsystem-4 proposal
Marco and Peter's proposal for defsystem 4 served as the driver for
many of the features in here. Notable differences are:
@itemize
@item
We don't specify output files or output file extensions as part of the
system.
If you want to find out what files an operation would create, ask the
operation.
@item
We don't deal with CL packages
If you want to compile in a particular package, use an in-package form
in that file (ilisp / SLIME will like you more if you do this anyway)
@item
There is no proposal here that defsystem does version control.
A system has a given version which can be used to check dependencies,
but that's all.
@end itemize
The defsystem 4 proposal tends to look more at the external features,
whereas this one centres on a protocol for system introspection.
@section kmp's ``The Description of Large Systems'', MIT AI Memu 801
Available in updated-for-CL form on the web at
@url{http://world.std.com/~pitman/Papers/Large-Systems.html}
In our implementation we borrow kmp's overall PROCESS-OPTIONS and
concept to deal with creating component trees from defsystem surface
syntax. [ this is not true right now, though it used to be and
probably will be again soon ]
@c -------------------
@node Concept Index, Function and Class Index, Inspiration, Top
@unnumbered Concept Index
@printindex cp
@node Function and Class Index, Variable Index, Concept Index, Top
@unnumbered Function and Class Index
@printindex fn
@node Variable Index, , Function and Class Index, Top
@unnumbered Variable Index
@printindex vr
@bye