Editing HIDE/Design/Project management (section)

== An API proposal ==

Each hIDE instance manages one project, so there is sort of a singleton object for the project management. Each project has a single root of its build tree. At the moment we expect there to be at most one .cabal file in that root directory.

=== Setting the build tree root ===
 ProjectManagement.setBuildTreeRoot :: FilePath -> IO ()

This operation sets the root of the build tree to the given directory. The initialisation function for the project management component should do:
 pwd <- getCurrentDirectory
 setBuildTreeRoot pwd

Of course this assumes that hIDE was invoked with no args, if it was invoked with hIDE /path/to/project/root then we'd use that as the build tree root.

=== Getting at the cabal package(s) ===
Then there should be a function to get the list of cabal projects in the build tree. This will only do anything after the build root has been set.

 ProjectManagement.getCabalPackages :: IO [CabalPackage]

The first version of this code will only assume there is at most one .cabal file and so will only return zero or one CabalPackages.

The CabalPackage object corresponds to a .cabal file. It will have a function to get the information from th file. This will re-use the data structures provided by the Cabal library.

Similarly it will provide function that perform the normal actions on cabal projects, like configure, build etc. This will probably be implemented using the Cabal library too.

=== Finding the package for a source file ===
There should also be a function to find the BuildInfo corresponding to a given source file. This is for cases like the interactive type checker. It needs to know what setting to use for any given source file. So it will use this function:

 ProjectManagement.getBuildInfoForFile :: FilePath -> IO (Maybe BuildInfo)

The project management component will figure out this mapping when the build tree root is set by reading the .cabal file(s) and figuring out which source files belong to it/them.

If a source file does not belong to any cabal package (for example if the user has not created any .cabal file or if it's merely some test module that is not part of the normal project build) then of course getBuildInfoForFile will return Nothing. In this case the interactive type checker would still be able to check the file but it would use default settings, as if the user were using ghc --make with no other flags.

Note that this allows us to extend things later for the case of more than one .cabal file in a build tree. Though it does make the (not unreasonable) assumption that each source file belongs to at most one cabal package.

=== Partial builds ===
On top of the above API it ought to be possible to implement a function which does a partial build starting from any given source file. This is basically the same as what the interactive type checker has to do.

=== Updating project settings ===

 ProjectManagement.setCabalPackage :: CabalPackage -> IO ()

This should write the .cabal file. Note that the CabalPackage object will need
to know the name of the file. For a new CabalPackage the default should be
taken from the package name. All listeners shuold be notified of the change in
this package.

Actually perhaps the setting should not be writte immediately to the file but cached at written later when appropriate. For example the GUI editor for the
project settings will generate changes live, but we don't want to write the
file every single keystroke.

=== Notification of changes to project settings ===

It should be posible to get notified when the setting for a cabal package change, or when a package is created or deleted. This will take the form
of registering a callback function.

We should decide if this callback is for all packages or per-package.

Components like the interactive type checking would want to be notified of changes in project setting so that can be reflected in the setting used during compilation. For example if a user adds an extra package to the build-depends field. Then the setting used for the interactive typechecking would need to be updated accordingly.