ghc_extra_opts in package

[Simon Marlow]

> > Also, this doesn't mesh well with the portability notion in the new
> > libraries proposal.  The idea there is that certain libraries would
> > be optional depending on whether the compiler implemented certain
> > extensions - with your scheme this would have to be done at the
> > package level.
>=20
> Hmmm, my mental model of packages was a group of tightly coupled
> modules so I wasn't making this distinction.

Reasons to split groups of modules into packages:

  - to avoid polluting the module namespace (historical;=20
    not an issue with the new library scheme).

  - for separate distribution/installation

  - if you put all your code in one package, the .a library
    can get large which might slow down linking.

Reasons not to use packages if you don't have to:

  - the user has to explicitly ask for a package (at least at
    the moment; it may be possible to remove this restriction in
    certain cases).

  - you can't have recursive dependencies between packages

Additionally restricting a package to use a single set of extensions
will probably be inconvenient both for the users and developers, at
least for the core package.

> > I wanted to lump all the core libraries into a single package on
> > GHC, but this would mean that package "core" for GHC would require a
> > different set of extensions than the same package for NHC.
>=20
> That's more because of conditional compilation than the
> library/package distinction right?
>=20
> Hmmm, conditional compilation complicates the story for=20
> source packages.
> Choices:
>=20
> o one package per combination of cpp flags
>=20
> o one package with some sort of conditionals inside it:
>=20
>   deps =3D case COMPILER of
>          __GHC__ =3D> net, lang
>          __NHC__ =3D> lang
>          __HUGS__ =3D> greencard
>=20
> Neither is very appealing.  Is there an existing story for this sort
> of thing?

The second way seems to me to be the only option, if you want to go down
this route.  For example, some of the Monad libraries require MPTC, but
I don't want to split these into a separate package - hence the core
package requires MPTC.  But NHC won't support these modules, so its core
package will be different.

It's more like conditional compilation at the module level - certain
modules will just be omitted altogether for certain compiler/platform
combinations.  Some conditional compilation may additionally happen in
the implementation, but the interface for a module should be static
across all implementations that support it.

Cheers,
	Simon