Inconsistent naming/usage for ghcjs-options?

[nh2]

I just noticed that when I specify ghc-options in a .cabal file for a ghcjs project, these options are passed to the ghcjs --make execution during the build.

But when I pass cabal build --ghc-options=..., those options are not passed to it; instead I need to use cabal build --ghcjs-options=....

This seems inconsistent to me, and puts me into a situation where the Cabal file format and the cabal command line flags work differently.

Is this an oversight or intended?

[23Skidoo]

/cc @luite

[23Skidoo]

Looks like an oversight to me.

[dcoutts]

Looks like an oversight to me.

It's not an oversight.

This is because the ${compiler}-options in the .cabal file and the --${prog}-options are actually different, but because they have the same literal name then people (not unreasonably) assume they mean the same thing.

The --${prog}-options is a generic mechanism to pass options to ${prog}. It knows nothing special for compiler or any other tools. It's just as if you had specified --with-${prog}=wrapper-script.sh that passes extra flags on to the program, whenever it gets called.

We've had this UI problem for ages. What can we do about it? Clearly we need a way to pass extra ad-hoc options to specific programs whenever they're called. But also we need compiler/toolchain options that behave appropriately, e.g. ghc, cc, ld etc options. For example, cc & ld options would want to be passed on to ghc, and not just when gcc/ld is invoked by the build system directly. And the other way around, those flags would be passed at appropriate times, not literally every time. For example when invoking ghc to get the --info or the ABI for some .hi files we don't need to pass other random options that a user intends for compiling, and not these other misc cases.

So what do we do? Perhaps if everyone thinks of --ghc-options as being the toolchain one, rather than the generic wrapper one, then we should rename the generic wrapper ones:

That is we would add --${toolchain}-options for specific parts of the system toolchain, including ghc, cc, ld.

And also rename the existing --${prog}-options to something else, like --program-${prog}-options. So --ar-options becomes --program-ar-options, and we end up with both --ghc-options (& --cc-options) as well as --program-ghc-options.

While we're thinking of UI, there's a similar issue with new-build with options to be passed to tools that affect the program output (and thus the content of the package, and so they should go into the hash) vs options that just affect things like verbosity etc and so should not go into the hash.

[mgsloan]

This actually caused unexpected issues in stack. See this ghcjs issue - https://github.com/ghcjs/ghcjs/issues/533#issuecomment-254523860 . Quoting Luite:

Hmm, might be a problem in cabal then: cabal should actually also respect ghc options for ghcjs, as a derived compiler. At least this was the original plan.

This makes it hard for tooling to treat GHCJS as if it's just GHC..

[nh2]

@dcoutts's proposal seems quite good to me.

With it, --ghc-options would be respected by both ghc and ghcjs, and --program-ghc-options and --program-ghcjs-options would be only for the respective compiler binary.

[mgsloan]

Seems reasonable to me as well!