I started looking at Edi Weitz's CL-FAD to pick up some good coding practices. One thing caught my eye when looking at cl-fad.asd
. In defsystem
Weitz uses :serial t
which, if I understand correctly based on the docs, instructs ASDF to include :components
in order of appearance. This, it seems to me, should make :depends-on
redundant in such a context. Is there a reason why Weitz included the :depends-on
anyway, or is it just an oversight?
Here's the defsystem
part (latest Github clone):
(asdf:defsystem #:cl-fad
:version "0.7.2"
:description "Portable pathname library"
:serial t
:components ((:file "packages")
#+:cormanlisp (:file "corman")
#+:openmcl (:file "openmcl")
(:file "fad")
(:file "path" :depends-on ("fad"))
(:file "temporary-files" :depends-on ("fad")))
:depends-on (#+sbcl :sb-posix :bordeaux-threads :alexandria))
(asdf:defsystem #:cl-fad-test
:version "0.7.2"
:serial t
:components ((:file "packages.test")
(:file "fad.test" :depends-on ("packages.test"))
(:file "temporary-files.test" :depends-on ("packages.test")))
:depends-on (:cl-fad :unit-test :cl-ppcre))
It is possible that doing both serial and on-depends would create a conflict, i.e. that the acyclic graph defined by the on-depends wouldn't be compatible with the ordering given by sequence of the components. I doubt, but who knows, if asdf actually checks for that.
So sure, that's redundant. But yeah, redundant isn't necessarily a bad thing. Stating the on-depends in addition to the serial might provide a bit-o-info for the reader about the structure of the code.
And the developer might occasionally comment out the serial to gain the benefits that follow from that.