ghc_extra_opts in package

[Alastair David Reid]

Simon Marlow <simonmar@microsoft.com> writes:
> Let's be clear: these extensions are those required by the
> *consumer* of the package, right?

Blink!  I hadn't been thinking of it that way.

For a binary package, I guess that is all it means but it seems that a
source package could/should distinguish between which flags you need
to compile the code and which to compile against it.

> 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.

Hmmm, my mental model of packages was a group of tightly coupled
modules so I wasn't making this distinction.

> 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.

That's more because of conditional compilation than the
library/package distinction right?

Hmmm, conditional compilation complicates the story for source packages.
Choices:

o one package per combination of cpp flags

o one package with some sort of conditionals inside it:

  deps = case COMPILER of
         __GHC__ => net, lang
         __NHC__ => lang
         __HUGS__ => greencard

Neither is very appealing.  Is there an existing story for this sort
of thing?

-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/

ps I've been thinking that we should add conditional compilation to
the list of extensions (but with the intention that all compilers
would support it).  I'm thinking all we need and want is conditional
compilation but #define's would be restricted to a config file (maybe)
and macro expansion would be limited to the expression part of #if.  I
think this is what Marcin put in hsc2hs so maybe he can comment?