Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix some GHC dependencies on iOS #40393

Merged

Conversation

ElvishJerricco
Copy link
Contributor

Motivation for this change

This fixes a few iOS related packages, particularly with the goal of fixing GHC dependencies. GHC itself does not quite build yet, but its dependencies do.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

/cc @ryantrinkle @Ericson2314

@ElvishJerricco ElvishJerricco requested a review from peti as a code owner May 12, 2018 06:22
@ElvishJerricco
Copy link
Contributor Author

@ryantrinkle I left out 47f2e72. @angerman seemed to think it should have worked as it was before. Could you clarify the purpose of that commit?

@ElvishJerricco
Copy link
Contributor Author

I also left out 1bb6287. I think it's better to just require people to use haskell.packages.integer-simple; that way they don't have to do overrides to work with the gmp version (which I believe we expect to have working eventually?)

@@ -402,6 +406,21 @@ stdenv.mkDerivation ({
export NIX_${ghcCommandCaps}PKG="${ghcEnv}/bin/${ghcCommand}-pkg"
# TODO: is this still valid?
export NIX_${ghcCommandCaps}_DOCDIR="${ghcEnv}/share/doc/ghc/html"
export LD_LIBRARY_PATH="''${LD_LIBRARY_PATH:+''${LD_LIBRARY_PATH}:}${
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting LD_LIBRARY_PATH in the generic builder is not a good idea. It's important that all relevant search paths are registered with Cabal because otherwise the generated library config file does not contain them and then libraries will fail to link when they're used by other components, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the right way to register this with Cabal?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In cc-wrapper. I'll do this once I get home. It will be mass rebuild however.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Err sorry that would be for the cflags link part. Maybe Cabal has an --extra-framework-dirs?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah but this is the shell env. @peti the env is really screwed up, you know, because the system-haskell division of deps does not take into account propagated dependencies. We drop propagated systems deps (including frameworks) on the floor since ghcWithPackages doesn't reexport them. I like the idea of ghcWithPackages, but it is very incompatible with the bash-heavy cc-wrapper way of doing things. More thought is needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll make a separate PR for --extra-framework-dirs. (edit done in #40442 and #40443.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ElvishJerricco let's try to land #39735 by @kirelagin for this reflex-platform release too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ericson2314 So you're going to tackle these env issues in a separate PR? Should I remove the env changes from this PR entirely?

# On macOS, statically linking against system frameworks is not supported;
# see https://developer.apple.com/library/content/qa/qa1118/_index.html
# They must be propagated to the environment of any executable linking with the library
, libraryDarwinFrameworkDepends ? [], executableDarwinFrameworkDepends ? []
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cabal refers to these dependencies simply as frameworks in its BuildInfo type, therefore I think we should adopt that nomenclature and simply call them framework here, too, rather than darwinFramework.

optionals (allPkgconfigDepends != []) allPkgconfigDepends ++
propagatedBuildInputs = buildDepends ++ libraryHaskellDepends ++ executableHaskellDepends ++ libraryDarwinFrameworkDepends;
otherBuildInputs = setupHaskellDepends ++ extraLibraries ++ librarySystemDepends ++ executableSystemDepends ++ executableDarwinFrameworkDepends ++
optionals (allPkgconfigDepends != []) ([pkgconfig] ++ allPkgconfigDepends) ++
optionals doCheck (testDepends ++ testHaskellDepends ++ testSystemDepends ++ testToolDepends) ++
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We require a testFrameworkDepends argument, too.

optionals (allPkgconfigDepends != []) allPkgconfigDepends ++
propagatedBuildInputs = buildDepends ++ libraryHaskellDepends ++ executableHaskellDepends ++ libraryDarwinFrameworkDepends;
otherBuildInputs = setupHaskellDepends ++ extraLibraries ++ librarySystemDepends ++ executableSystemDepends ++ executableDarwinFrameworkDepends ++
optionals (allPkgconfigDepends != []) ([pkgconfig] ++ allPkgconfigDepends) ++
optionals doCheck (testDepends ++ testHaskellDepends ++ testSystemDepends ++ testToolDepends) ++
optionals doBenchmark (benchmarkDepends ++ benchmarkHaskellDepends ++ benchmarkSystemDepends ++ benchmarkToolDepends);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto with benckmarkFrameworkDepends.

optionals (allPkgconfigDepends != []) allPkgconfigDepends ++
propagatedBuildInputs = buildDepends ++ libraryHaskellDepends ++ executableHaskellDepends ++ libraryDarwinFrameworkDepends;
otherBuildInputs = setupHaskellDepends ++ extraLibraries ++ librarySystemDepends ++ executableSystemDepends ++ executableDarwinFrameworkDepends ++
optionals (allPkgconfigDepends != []) ([pkgconfig] ++ allPkgconfigDepends) ++
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pkg-config is up above as a native build input.

@@ -402,6 +406,21 @@ stdenv.mkDerivation ({
export NIX_${ghcCommandCaps}PKG="${ghcEnv}/bin/${ghcCommand}-pkg"
# TODO: is this still valid?
export NIX_${ghcCommandCaps}_DOCDIR="${ghcEnv}/share/doc/ghc/html"
export LD_LIBRARY_PATH="''${LD_LIBRARY_PATH:+''${LD_LIBRARY_PATH}:}${
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In cc-wrapper. I'll do this once I get home. It will be mass rebuild however.

@@ -402,6 +406,21 @@ stdenv.mkDerivation ({
export NIX_${ghcCommandCaps}PKG="${ghcEnv}/bin/${ghcCommand}-pkg"
# TODO: is this still valid?
export NIX_${ghcCommandCaps}_DOCDIR="${ghcEnv}/share/doc/ghc/html"
export LD_LIBRARY_PATH="''${LD_LIBRARY_PATH:+''${LD_LIBRARY_PATH}:}${
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Err sorry that would be for the cflags link part. Maybe Cabal has an --extra-framework-dirs?

@@ -1,14 +1,18 @@
{ stdenv, appleDerivation }:

appleDerivation {
preConfigure = "cd libiconv";
preConfigure = "cd libiconv" #TODO: This `cd` should be in postUnpack, not preConfigure; otherwise, autoreconfHook breaks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This TODO is done on staging.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ericson2314 So I should remove this preConfigure entirely?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly not, because I can't figure out how to get autoreconf hook to work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So then what do you want me to do with this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep the below part but get rid of the comment so that specific line is unchanged.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ericson2314 I should switch this from stdenv.hostPlatform != stdenv.buildPlatform to something like hostPlatform.isDarwin or something, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could do hostPlatofrm.isiOS. This is already a Darwin-specific version of libiconv.

@ElvishJerricco
Copy link
Contributor Author

@Ericson2314 Also, should this PR be pointing at master or staging?

@Ericson2314
Copy link
Member

@ElvishJerricco by the rebuild count I guess staging? We can still base them off a master commit so we can use them without pulling in as much of a rebuild I suppose.

@ElvishJerricco
Copy link
Contributor Author

@Ericson2314 what about the env changes? Should I remove those from this PR?

@ElvishJerricco
Copy link
Contributor Author

@Ericson2314 ping

optionals doBenchmark (benchmarkDepends ++ benchmarkHaskellDepends ++ benchmarkSystemDepends ++ benchmarkToolDepends);
propagatedBuildInputs = buildDepends ++ libraryHaskellDepends ++ executableHaskellDepends ++ libraryFrameworkDepends;
otherBuildInputs = setupHaskellDepends ++ extraLibraries ++ librarySystemDepends ++ executableSystemDepends ++ executableFrameworkDepends ++
optionals (allPkgconfigDepends != []) ([pkgconfig] ++ allPkgconfigDepends) ++
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you add [pkgconfig] here? It's already part of nativeBuildInputs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I had a comment on that too but GitHub evidently ate it.

@Ericson2314
Copy link
Member

Ericson2314 commented May 16, 2018

@ElvishJerricco lets just land the framework changes (maybe on 18.03, too) and then return to the rest of this.

@ElvishJerricco ElvishJerricco force-pushed the ios-prebuilt-dependency-fixes branch 2 times, most recently from febf5aa to 5120c8c Compare May 16, 2018 17:56
@ElvishJerricco
Copy link
Contributor Author

@Ericson2314 I've removed all the changes to generic-builder and the comment in libiconv, and I've switched the condition in libiconv to isiOS. Does that make this merge-able?

@Ericson2314
Copy link
Member

@ElvishJerricco see 62fd669 on staging, it should be targetPrefix now. That's the last thing

Overall, I wanted to start with the framework depends (outside env) because that is unambiguously a good thing, whereas these most of these are our grosser hacks I'm fine not upstreaming until the last second.

Ericson2314
Ericson2314 previously approved these changes May 16, 2018
@@ -59,6 +59,7 @@ nodePackages // {

ios-deploy = nodePackages.ios-deploy.override (oldAttrs: {
preRebuild = ''
LD=$CC
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is another default-v*.nix that probably needs this too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@Ericson2314 Ericson2314 dismissed their stale review May 16, 2018 18:16

pushed wrong radio button

@ElvishJerricco
Copy link
Contributor Author

@Ericson2314 Yes, the targetPrefix thing was fixed in the second commit. I'll squash the first one away.

With the generic-builder stuff gone, this PR is pretty small. I don't really see anything particularly gross.

Needs to link with a C compiler, not linker directly
@Ericson2314
Copy link
Member

OK will merge. I don't like not being able to run autoreconfHook and having to sed instead but whatever; stuff is small. :)

@Ericson2314 Ericson2314 merged commit f3fcf1b into NixOS:master May 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants