cabal install ignores --enable-executable-dynamic flag
#8909
Assignees
Comments
|
I remember diagnosing this or a similar issue in the past. There should be a ticket with |
|
The closest I'm able to find are:
But they're not exactly the same: they talk about |
|
This is another instance of #7297. The |
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Jan 8, 2024
Currently, there are three kinds of cabal configurations considered when
determining an option of an `ElaboratedConfiguredPackage`:
* Global configuration, in `.cabal/config`
* Local configuration, in
- Options passed in the cabal invocation, e.g. `cabal build --enable-executable-dynamic`
- Fields in the top level `cabal.project`, or `cabal.project.local`, e.g. `extra-include-dirs: /opt/homebrew/include`
Note thus that top-level cabal.project flags and cli flags are
treated all together at the same level (`local`).
* Per package configuration, as in
package HsOpenSSL
extra-include-dirs: /opt/homebrew/Cellar/openssl@3/3.2.0_1/include
extra-lib-dirs: /opt/homebrew/Cellar/openssl@3/3.2.0_1/lib
Then, we have a definition for whether a package is local to the
project. The local packages are the packages listed in the project which
have a specific source package, rather than just being listed by name in
a `source-repository-stanza`, or in a `package <package-name>` stanza
that configures installed packages.
In this patch, we try fix the mistmatch between the `local` flags and the
packages which are deemed `local`, and define a specification for what
exactly should happen..... TODO
Fixes haskell#7297, haskell#8909, haskell#2997
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Feb 1, 2024
Currently, there are three kinds of cabal configurations considered when
determining an option of an `ElaboratedConfiguredPackage`:
* Global configuration, in `.cabal/config`
* Local configuration, in
- Options passed in the cabal invocation, e.g. `cabal build --enable-executable-dynamic`
- Fields in the top level `cabal.project`, or `cabal.project.local`, e.g. `extra-include-dirs: /opt/homebrew/include`
Note thus that top-level cabal.project flags and cli flags are
treated all together at the same level (`local`).
* Per package configuration, as in
package HsOpenSSL
extra-include-dirs: /opt/homebrew/Cellar/openssl@3/3.2.0_1/include
extra-lib-dirs: /opt/homebrew/Cellar/openssl@3/3.2.0_1/lib
Then, we have a definition for whether a package is local to the
project. The local packages are the packages listed in the project which
have a specific source package, rather than just being listed by name in
a `source-repository-stanza`, or in a `package <package-name>` stanza
that configures installed packages.
The reason why local packages being installed are treated as non-local
is that TODO
In this patch, we try fix the mistmatch between the `local` flags and the
packages which are deemed `local`, and define a specification for what
exactly should happen..... TODO
Fixes haskell#7297, haskell#8909, haskell#2997
|
Fix in #9697. |
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Feb 5, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297 haskell#8909 and the install part of haskell#7236
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Feb 6, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297 haskell#8909 and the install part of haskell#7236
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Feb 6, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297, haskell#8909, the install part of haskell#7236, haskell#8529, haskell#7832
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Feb 6, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297, haskell#8909, the install part of haskell#7236, haskell#8529, haskell#7832
mpickering
pushed a commit
to alt-romes/cabal
that referenced
this issue
Feb 6, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297, haskell#8909, the install part of haskell#7236, haskell#8529, haskell#7832
Mikolaj
pushed a commit
to alt-romes/cabal
that referenced
this issue
Feb 9, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297, haskell#8909, the install part of haskell#7236, haskell#8529, haskell#7832
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Feb 9, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297, haskell#8909, the install part of haskell#7236, haskell#8529, haskell#7832
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Feb 9, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297, haskell#8909, the install part of haskell#7236, haskell#8529, haskell#7832
|
Fixed by #9697 |
erikd
pushed a commit
to erikd/cabal
that referenced
this issue
Apr 22, 2024
The target of `cabal install` is not considered to be a local package, which means local configuration (e.g. in cabal.project, or flags like --enable-profiling) does not apply to it. In 76670eb, we changed the behaviour to applying the local flags to cabal install targets, but it used the literal target string as a package name to which the flags were additionally applied. However, `cabal install` targets are NOT necessarily package names, so, e.g., if we did `cabal install exe:mycomp`, the local flags would not apply since "exe:mycomp" is not a recognized /package/. The solution is to parse the target selectors first, and apply the local flags to the package of the resolved targets. Fixes haskell#7297, haskell#8909, the install part of haskell#7236, haskell#8529, haskell#7832
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The bug
There is no (obvious) way to have
cabal installa dynamically linked executable.To Reproduce
With the following configuration
if I run
cabal install --enable-executable-dynamic, then a statically linked version of the executable gets installed:Expected behavior
System information
Additional information
I can get around the problem by putting
ghc-options: -dynamicin thepackage.cabalfile, but I don't think it's the appropriate solution.The text was updated successfully, but these errors were encountered: