Deprecate haskell-site-file.el

[hvr]

If we can drop support for Emacs versions prior to 23.1 (which was released in 4 years ago, and the earliest version for which package.el/ELPA support is possible), we should get rid of the autoloads haskell-site-file.el file altogether (it was removed from the git repo via ae7cee0) as this file becomes obsolete thanks to package.el:

I've been reading up on Preparing Lisp code for distribution and found out that if we generate a .tarball following the requirements for Multi-file Packages we don't have to generate the autoloads at all. In the contrary:

Do not include any .elc files in the package. Those are created when the package is installed. Note that there is no way to control the order in which files are byte-compiled.

Do not include any file named name-autoloads.el. This file is reserved for the package's autoload definitions (see Packaging Basics). It is created automatically when the package is installed, by searching all the Lisp files in the package for autoload magic comments.

Even if we don't upload the package .tar-file to any package repository, it can still install be installed directly via M-x package-install-file.

Therefore I propose that the Makefile build-system shall support the following two use-cases:

• Generate easy to install M-x package-install-file-compatible .tar file for end-users (and Linux distributions)
• Generate "in-place" distribution for developers (basically what make all does now already)

This would also help reduce the hacks currently contained in Makefile (see 896c422 and 8d3edf5)

[chrisdone]

Sounds good to me.

[bergey]

The README still references building the haskell-site-file with make

[hvr]

@bergey thx!