我有一个主要的Haskell可执行程序与cabal文件.在那里,我指定了ghc-options.
这个可执行文件链接到荒野中的其他库.将ghc-options这些库的阴谋文件被忽略？
我基本上想知道可执行文件是否ghc-options将用于整个enchilada(主要的可执行文件+库).
其他赏金指出:还请扩大下面志的评论,即究竟是什么之间的差异ghc-options为编译与链接.在图书馆中哪些是哪些,哪些是永远不需要的？也许你可以谈谈一些最重要的,如-threaded下面提到的.
在正常cabal-install工作流程（以及stack在其之上构建的工作流程）下，Cabal 文件中指定的标志对于您的包而言是本地的，并且不应触发重建。同样，--ghc-options在命令行上指定的选项对于您的包来说是本地的。
对于您关于 的具体问题-threaded，此标志对库代码没有影响（正如cabal-install将告诉您的那样），仅对可执行文件有影响。
此处提供了 GHC 标志的简短列表。特别要注意的是，-threaded它列在Linking options下，并进一步链接到Optionsfluenceing linking。从这些信息中，我们得出结论，这只-threaded对可执行文件有意义，因为它向 GHC 发出信号，表明我们希望使用线程运行时。如果您的包不提供可执行文件，则它不需要任何运行时、线程或其他方式。
对于编译与链接的高级解释：它们是源代码和可执行文件之间的两个步骤。编译是从源代码生成目标文件的过程。链接是连接组成可执行文件的众多目标文件的过程。当你编译一个可执行文件时，它不知道一个函数是否map存在，除非你定义了它，所以它只是在假设它存在的情况下进行编译。在链接步骤中，我们使所有这些名称可用且有意义。在 的情况下-threaded，我们使链接过程了解线程运行时，运行时上调用的所有代码都将使用该运行时。
由于我不知道您使用的是标准cabal工作流程stack还是新cabal.project工作流程，所以这里离题一下，讨论一下案例中的这种行为cabal.project。
现在这实际上是一个未解决的错误。
该错误在 Cabal GitHub 上被跟踪为问题3883（以及相关问题4247）。
与您的问题相关，根据当前的行为，在ghc-options文件的节中指定标志cabal.project会导致使用这些标志来编译（或重新编译，视情况而定）这些依赖项。