(no subject)

[C.Reinke]

> I'd argue that -package is a global option and should stay that way.
> The only reason you might want to disable -package for certain
> modules and not others is if you want to do some tricks with module
> shadowing - and this definitely isn't supported in GHC.  You should
> pass the same -package to every compilation.

Funny, I wasn't actually thinking of hiding -package (effectively
giving it a scope) when I wrote that. AFAIC, it would be fine for
GHC to collect all the -package options from the source files it
wants to compile and then use the same superset of package options
for all of them (*).

But it would be helpful if each source collection could include the
information ghc needs to compile it. So if I have sources A that
happen to need -package HOpenGL and sources B that happen to need
-package lang, etc., I could simply document those dependencies in
the sources in a way ghc would understand. And if I have a project C
using both A and B, and I need to modify anything in A or B, I could
still simply let "ghc --make C" figure out what to do by just
telling it where to find A and B. Whereas currently, I have to go
back and figure out what packages A or B need to be compiled with..
(or not use ghc --make, before anyone else suggests that;-).

> I think -i is a global option in the same sense as -package, though.
> The library options -l and -L don't really matter, since they're
> only used at link time and you wouldn't want to put them in OPTIONS
> anyhow.

Same here, for non-package dependencies.

Claus

(*) I didn't want to have global supersets of options for language
extension flags, but those seem to be dynamic anyway, and often,
their effects spill over to anything wanting to use the modules that
use language extensions.