* misc

** give usage message before erroring when no description file?
** give better error message for missing description file

** unregistering the package, etc

*** think about HC-PKG's role here. maybe HC-PKG should do all this
   instead
*** Should "setup install" copy Setup.lhs, Setup.description, and
   local-build-info into a common location for the sake of unregister?
   Will we have to make this a requirement of 'install'? (suggested by
   kosmikus) Would it be better for HC-PKG to have the unregister
   command?
*** Add a flag to configure to specify where to put them?

** integrate w/ GHC distro

** what other preprocessors can't unlit?

** Hugs
- look for "FIX (HUGS)"
- can't handle cabal's OPTIONS pragmas at the top. this requires
  getting cpp to work from the Setup.description file.
- no way to tell Hugs to turn packages on or off
- no register / unregister for hugs

** find a real test case that uses a preprocessor

** for a source tarball:?
- if there's a flag, --include-preprocessed-sources (or something
   better) run the preprocessing phase and include both the
   unpreprocessed and the preprocessed sources in the source tarball?

** clarify description filename issues
- allow foo.hsproj?

** grep for "FIX"

** Compatibility
*** add information for compiling w/ nhc
*** add install target for hugs & nhc
*** Make runhugs stuff work
*** verify windows test suite
*** Better way to find 'tar'; is there a library? what does darcs do?

** Doc
*** do comments have to start in the first column?
*** clarify relationship between exposed-modules and modules, etc.
*** add preprocessor explanation (see bottom of this TODO).
*** Fix example for angela, expose Data.Set, etc, not A, B, etc.b
*** add information about executable stanzas
*** elimintate need for cpphs in haddock makefile rule.

** look carefully at "rawSystem" and error handing stuff for nhc.

** It actually makes sense to have several libraries ("hs-packages")
   in one package ("cabal-package"), look at wxhaskell for example.
   - So, Library stanzas, I suppose
   - ./setup build should take an optional list of build targets
     (that is, library and executable names)
   - The overloaded terminology is *way* confusing. Feh.
** API Versioning? Libtool-style or just a major number?
** Extensions
- complain if their use makes the code non-portable?
-- but what does this mean? ghc & hugs?

** Reorganize compiler dependent code into Distribution.Compiler.*

** Parsing
*** Parser error reporting
*** Allow quoting in the options fields, to allow things like
   -f"something with spaces"
*** Instead of freaking out on unknown fields, the parser should return
    a list of those unknown fields so a warning can be printed. Or not.


* 1.0 
** add a make target or command for tests we know will fail?
** HC-PKG (see "Depends on HC-PKG" below)
** ./Setup.lhs build for nhc
** ./Setup.lhs bdist
** add more layered tools to appendix?
** make reference to "layered tools" appendix where approprote
** integrate hscpp, use it for preprocessing step.
** SDist for windows machines, or machines without tar.
** sanity checking tool for configuration; are all the .hs files
   included, etc.

* testing
** setup test suite to run on --push?
** redirect non-hunit outputs to a file?
** test / port code for Hugs and nhc
** error cases for parsing command-line args
** reading & writing configuration-dropping
** use-cases based on SimonPJ's doc
** discovering the location of the given flavor of compiler and pkg tool

* Depends on HC-PKG
** buildDepToDep in Configure doesn't set version dependency
** nhc-pkg (see old package manager code)
** hugs-pkg
** register
*** for hugs & nhc
** configure: check for presence of build dependencies

* Misc
** create a (native?) zlib library?

** sign flag?

** for fields like allModules, allow user to specify "Foo.Bar.*" or
   something to indicate all haskell modules under that?

** Get function from hmake that creates a directory based on arch.

** ./Setup test
- this may be something that's easy to break off and give to someone
   else.
- give to John Goerzen?

** writePersistBuildConfig robustify + diagnostics
** elaborate command-line help text
** configure should check for 'ar' args + properties (see fptools/aclocal.m4)
** most commands should accept a -v flag to show command lines?
** configure should check sanity of PackageDescription, eg. library /= "" ?
** configure should check version of compiler

------------------------------------------------------------
* Setup Command-line interface
** Actions
- build
- install (+maybe installprefix, maybe system)
- configure (+flags)
- packageinfo
- sdist
- clean
- register (maybe system)
- unregister (maybe system)

** flags
--help
--ghc
--nhc
--hugs
--with-compiler=
--prefix=
--instprefix=

* 1.0
** actions
- bdist
- doc stuff?

** flags
--hbc
--helium
--with-compiler=


------------------------------------------------------------

* Priorities for first beta release
(basically what was in SPJ's document):

** Basic command-line interface for configure, build, install,
   register, unregister, info
** Ability to wrap make
** basic build system (think hmake)
** binary distributions?

* Priorities for 1.0
** binary distributions?
** basic pre-processor extensions
** hat support
** haddock support
** user use configuration vs system use configuration

* looking ahead
** per-system source database
** rebuild for new compiler

* Orthogonal (layered?) tools

** visual studio support

** public database of packages

** downloadable public database of packages (wget filename;tar xf
   filename;cd filename;./setup install)

   NOTE: such an interface might be implemented w/ xml-rpc, which is
   there for Haskell now, though in general we'll probabliy want to be
   careful here about dependencies.

** debian package building (boilerplate) tool.  Other debian support
   w/ rebuild-all-packages?

------------------------------------------------------------
[1] Foo.y is a happy grammer which, when processed, will produce Foo.hs.

The description file should include the module Foo.

./setup sdist (source distribution): Include Foo.y, not Foo.hs.  Maybe
we could add a flag to include Foo.hs as well.  This makes sense for
some preprocessors and not for others, but I'm wary of including too
much preprocessor-specific behavior.

./setup clean: Removes Foo.hs if Foo.y exists.

./setup build: Preprocesses Foo.y to Create Foo.hs before any
compilation.

The issue with cpp is that we can't go by extensions as we do with the
rest of the preprocessors... There is a function in HMake which tests
to see if a file needs to be cpp'd, so we can employ that.  I think
we'll probably have to just treat cpp a little differently from the
others, unfortunitely, and I haven't gotten around to it.
