Foreign.GreenCard.StdDIS (was Re: X11 libraries)

[Simon Marlow]

=20
> When I got back to work on putting an HGL release together, I=20
> realized that=20
> I'd have to do a fresh release of GreenCard first since it=20
> has a bunch of=20
> updates to work with hierarchial names, ffi, etc.  The=20
> GreenCard distrib=20
> contains what ought to be the master copy of the=20
> StdDIS.{gc,hs} so I figure=20
> it ought to be made a proper library package, put in the=20
> hierarchial library=20
> namespace, etc.  Obvious places to put it in the library=20
> hierarchy are:
>=20
>   Foreign.GreenCard.StdDIS.hs
>   GreenCard.StdDIS.hs
>   Apps.GreenCard.StdDIS.hs
>   <SomeOtherPrefix>.GreenCard.StdDIS.hs

There is reasonable justification for each of these - I don't have any
strong preferences.  Malcolm prefers Foreign.GreenCard.hs; that's fine
by me.

> (btw it seems like we might see more apps with support=20
> libraries -especially=20
> if the app generates Haskell code- so this may be an instance=20
> of a more general problem.)

FWIW, in Happy and Alex I just copy some boilerplate code directly into
the generated Haskell to avoid this problem.  The boilerplate isn't
baked into the Happy or Alex binary, it's installed as a separate file.

> [btw GreenCard raises an additional issue for any library=20
> building/ packaging=20
> infrastructure.  If you want to use GreenCard, you need=20
> StdDIS.gc and (the=20
> makefile which invokes) GreenCard needs to know where to find=20
> it.  So we need=20
> a standard place for it to live or a way to locate it once installed.]

We've solved this problem several times (GHC, hsc2hs, Happy, Alex,
Haddock).  The solution I normally use for Unix systems is to have a
small script which invokes the main binary passing it a flag which
indicates the location of its auxiliary files (usually something like
/usr/local/lib/happy).  You can build a location-independent binary
package which just fiddles with this script at install time.  On
Windows, it's rather easier because a binary can get at its own
filesystem location at runtime.

This all assumes the user normally wants the standard StdDIS.gc and
won't want to fiddle with it, I guess.

Cheers,
	Simon