I looked at two project framework generators: quickproject and
Quickproject creates a quick and simple project, particularly good for things that are only going to be one or two source code files in size.
Cl-project goes a bit further and automatically created a test package as well and created source and testing directories. Cl-project also creates a tiny asd package to avoid interning any symbols in the asd file to cl-user package. (This was explained to me by the author, Eitarow Fukamachi, I did not figure this out on my own.)
Cl-project pushes the package file down into the source directory. As a personal preference, I prefer the package file (the file that provides the defpackage, export and use declarations) up at the top directory level, next to the asd file. But I think that is personal preference and you can easily move it to one place or the other. In creating the test-package, cl-project automatically pulls in cl-test-more as the testing package.
My wish list for the next iteration for either package is (1) a :testing-framework keyword allowing you to specify the testing framework (and, in the case of quickproject, automatically setting up a testing package and both a source and testing directory), (2) automatically adding a docs directory (a reminder to programmers that library users get a lot out of documentation such as tutorials - do not expect them to simply glance at the source code and understand all the wonderfull work you have done), (3) automatically adding an :export entry for completion (the author uses @export annotation of cl-annot https://github.com/arielnetworks/cl-annot, so he does not use :export the way I use it), (4) a :use keyword allowing you to specify what other packages are used, if any and (5) since it creates a gitignore file, can it take a :version-control keyword and and actually create the initial base, either in git, svn, mercury or darcs. Oh, but we don't have the libraries to do that - so Sabra, what are you going to do about that? Stop complaining and start coding.
Author: Zach Beane of quicklisp fame.
results in 4 files: README.txt Test-project2.asd Test-project2.lisp and package.lisp.
After the project has been created, quickproject also adds its pathname to ASDF:*CENTRAL-REGISTRY*, so the project is immediately loadable via <tt>ASDF:LOAD-SYSTEM
Note the fact that I used initial caps in the name for the project and that was passed into the Name, but the defsystem declarations are all lower case. Both quickproject and cl-project handled this the same way.
The asd file reads as:
The package file reads as:
The lisp file reads as:
As expected, the README.txt file is just a stub.
Redditor Joekarma posted the following:
"I use quickproject. I added the following to my .sbclrc file to take care of the git repo initialization problem. You'll notice it also sets the README format to markdown--this is my preferred format because it works well with Github.(setf quickproject:*after-make-project-hooks*
(lambda (pathname &rest args)
(declare (ignore args))
(nix:chdir (fad:pathname-as-directory pathname))
(rename-file "README.txt" "README.markdown")
(list "init" "."))
(list "add" "."))
(list "commit" "-m" "Initial commit")))))
You'll have to quickload some libraries first:
Author: Eitarow Fukamachi, of clack and caveman (web application framework) fame.
A few things to note here. First, the system actually creates a .gitignore file which immediately fills itself with various fasl extensions to ignore. Second, the readme is markdown, rather than text. Third, cl-project creates source and test directories and automatically creates a test package as well as your intended package. Fourth, cl-project accepts a description keyword, which quickproject does not.
Unlike quickproject, cl-project doesn't create the link in ~/quickload/local-projects on new generated projects . If you create your projects under ~/quickload/local-projects, quicklisp will be able to quickload it, but if you put it somewhere else, you should create a link to your project.
The README.markdown file is slightly more than a stub, providing a bit more than quickproject:
A few things to note in the asd file. First, it provides a version and long-description for the defsystem.The asd file pulls the README.markdown file into the long-description of the asd file. Unlike quickproject, the generated defsystem does not provide :serial t.
cl-project also does not provide a separate package.lisp file. The defpackage information is, rather, put into the named lisp file in the source directory. E.g.:
Now looking at the test package created, cl-project creates both a test package and a test directory. As expected, the test package depends on and uses your new package, but it also depends on and uses the package cl-test-more. You can, of course, substitute the testing package of your choice. (Why do we have 27 different testing frameworks?)