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