Library Infrastructure Proposal & Home Page

[Isaac Jones]

Ross Paterson <ross at soi.city.ac.uk> writes:

> I'd prefer to have authors write data rather than a program, because
> programs can only be executed, but you can find other uses for data.

Indeed, this is one of my arguments against using Make.

There are several ways the author can do things, and I think that the
Setup.lhs script offers the most flexibility.

The information that the author needs to provide is basically the
Package data type from section 4.3.

We could have a file, lets call it setup.conf, which contains that
information.  The Setup.lhs script can parse setup.conf if it exists
(there will be functions to do this in the distribution module), and
so the Setup.lhs script would be basically:

> import Distribution
> main = do pkg <- readSetup
>           distUtilsMain pkg

There are two ways which you can offer access to the data for your
"other uses":

* distutilsMain (which should probably be called distributionMain)
  implements the 'info' command which will dump out the configuration
  information (see section 3.3)

* Or other tools can parse the setup.conf file if they want the
  package information

So I think that a setup.conf file would be very useful.  I'll add this
as a suggestion to the document.

There is another possibility also.  Each module could bind this
package information to "moduleInfo", so that MyPackage.moduleInfo
would give me the package information, and the setup script could
import this.  Then we'd have

> import Distribution
> import MyPackage.Info -- or something
> main = distutilsMain MyPackage.moduleInfo

BUT I wouldn't want to have to parse the setup.conf file to get the
info from MyPackage.moduleInfo since I don't want to do any IO, and I
don't want to have _both_ setup.conf and MyPackage.moduleInfo since
they're redundant.

So my proposal would be to forget the setup.conf file, standardize on
"moduleInfo" (or something) and if a non-haskell tool wants to get the
package information directly from the package, it can use "Setup.lhs
info".

So we'd be parsing the output from stdout instead of a file, or we
could add a -o flag to Setup.lhs to dump to a file that can be parsed
by other tools.

Arguments for including the executable program are that

1) it can do things that distutilsMain doesn't do.  That is, it brings
   the full power of Haskell to the developer

2) it can wrap an entirely different build system (a make-based system
   for instance) and still offer the same interface as all of the
   tools that use distutilsMain.

Neither of these is possible if we had _just_ setup.conf and
distUtilsMain as an external program.

> Also programs are likely to include boilerplate that can get out of
> date more quickly.

The boilerplate should be in distUtilsMain, which won't be included in
the Setup script, but with the Distribution module.


peace,

isaac