CL-FAD - redundancy in defsystem?

Question

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))

Answer 1

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.

Answer 2

Friends don't let friends use cl-fad.

cl-fad is the wrong place for "best practices" of any kind. It's a quick and dirty not-so-portable portability layer.

Use UIOP instead.