package descriptions

Isaac Jones ijones at
Wed Jan 5 11:32:28 EST 2005

ross at writes:

> (2) Packages using the simple build infrastructure would optionally
>     provide an additional file of build parameters for that infrastructure,
>     consisting of a basic stanza and zero or more executable stanzas:

I really don't think that requiring another file is a good idea.  Ross
& I have been talking in private email about how to get away with
using this 2nd file only in the case where it's necessary to perform
some external configure step that has to alter a file.

I want to keep the burden of extra complexity upon those with complex
libraries and tools to package.  People with very simple libraries and
tools shouldn't have to worry about which fields belong in which files.

My proposal was to optionally have the 2nd file (Setup.buildinfo) and
to allow it to override the non-required fields or the non-static
fields from the 1st file (Setup.description).  The file only gets
input if the user uses the hooks and defaultMainWithHooks.

That said, it's probably a good idea to split up the data types
themselves to reflect the distinction between static info and build

This proposal adds a little complexity to the file parsing, since we
have to have this override mechanism (I checked in a prototype a few
days ago).  This adds a little more complexity for hooks authors,
perhaps, but maybe not much if we break up the types the way Ross
suggests.  But it keeps the complexity where it belongs, and away from
Angela, the very simple module Author who just wants to get her tool
into Hackage, building on all platforms for all compilers, and who
already thinks it's strange that we make her pick a license and write
a version number.



More information about the Libraries mailing list